Manipulation of virtual and live computer storage device partitions

ABSTRACT

The present invention provides tools and techniques for manipulating virtual partitions in a virtual engine environment without necessarily committing each partition manipulation by actually modifying on-disk system structures. A virtual engine, virtual partitions, virtual drives, and other structures in the virtual engine environment permit users to experiment with different partition manipulations in a safe and efficient manner. A batch manager manages a resulting list of partition manipulation operations, which may be optimized. The batch list may also be executed automatically by a conventional partition manipulation engine without requiring additional user input at the end of each list entry. The present invention also provides the ability to manipulate extended partitions automatically and provides support for remote partition manipulation through a two-part user interface architecture.

RELATED APPLICATIONS

This application builds on and incorporates by reference the disclosurein commonly owned copending provisional patent application Ser. No.60/083,982, filed May 1, 1998 (“the '982 application”). This applicationalso builds on and incorporates by reference the disclosure in commonlyowned copending provisional patent application Ser. No. 60/090,213,filed Jun. 22, 1998 (“the '213 application”).

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever. The copyright owner does not hereby waive any of itsrights to have this patent document maintained in secrecy, includingwithout limitation its rights pursuant to 37 C.F.R. §1.14.

FIELD OF THE INVENTION

The present invention relates to manipulation of actual and simulatedcomputer storage device partitions, and more particularly to uses ofsimulation to help experiment with, undo, and optimize manipulations ofcomputer disk partitions that contain user data.

TECHNICAL BACKGROUND OF THE INVENTION

Computer hard disks and other computer storage devices hold digital datawhich represents numbers, names, dates, texts, pictures, sounds, andother information used by businesses, individuals, government agencies,and others. To help organize the data, and for technical reasons, manycomputers divide the data into drives, partitions, directories, andfiles. The terms “file” and “directory” are familiar to most computerusers, and most people agree on their meaning even though the details ofwritten definitions vary.

However, the term “partition” is unfamiliar to many people, and the term“drive” has different meanings even when the context is limited tocomputers. As used here, a “partition” is a region on one or morestorage devices which is (or can be) formatted to contain one or morefiles or directories. So-called “IBM-compatible partition” types includeextended, logical, and primary, as indicated by bitflags or othervalues. More generally, each formatted partition is tailored to aparticular type of file system, such as the Macintosh file system, SunOSfile system, Windows NT File System (“NTFS”), NetWare file system, orone of the MS-DOS/FAT file systems (MACINTOSH is a mark of AppleComputer, Inc.; SUNOS is a mark of Sun Microsystems, Inc.; WINDOWS NTand MS-DOS are marks of Microsoft Corporation; NETWARE is a mark ofNovell, Inc.). A file system need not fill the partition which holds it.

“Drive” is sometimes used interchangeably with “partition,” especiallyin references to logical drive C: or the like on so-called Wintel orIBM-compatible machines. But “drive” may also refer to a single physicalstorage device such as a magnetic hard disk or a CD-ROM drive. To reduceconfusion, “drive” will normally be used here to refer only to storagedevices, not to partitions. Thus, it is accurate to note that apartition often resides on a single drive but may also span drives, anda drive may hold one or more partitions.

It is often useful to manipulate partitions by creating them, deletingthem, moving them, copying them, changing their size, changing thecluster size used by their file systems, and performing otheroperations. A number of tools for manipulating partitions arecommercially available, including the FDISK program and thePartitionMagic® program (PARTITIONMAGIC is a registered trademark ofPowerQuest Corporation). Version 4.0 of the PartitionMagic® program,which became publicly available during September 1998, implementsaspects of the present invention. Partition manipulation is alsodiscussed in detail in U.S. Pat. Nos. 5,675,769 and 5,706,472 (hereafterthe '769 and '472 patents, respectively) and in commonly owned U.S. Pat.Nos. 6,108,759 filed Sep. 17, 1997, U.S. Pat. No. 5,930,831 filed Apr.11, 1997, U.S. Pat. No. 6,250,300 filed Aug. 15, 1998, and U.S. Pat. No.6,108,697 filed Oct. 2, 1998, each of whose respective discussions ofpartition manipulation tools and techniques are incorporated herein.

A Windows NT Disk Administrator program allows the user to delete orcreate partitions essentially in a virtual fashion, but its support formultiple “virtual” commands is limited. The user is allowed to create apartition, but must “commit changes” before that partition can beformatted. Formatting a partition can only be performed immediately.Other programs that manipulate partitions include version 3.0 of thePartitionMagic program, one or more versions of a QuarterdeckPartition-It program, and one or more versions of two programs from VCommunications sold under the names System Commander Deluxe andPartition Commander. Each of these programs generally force the user tomake one partition manipulation at a time.

FIG. 1 illustrates familiar approaches to partition manipulation. A user100 supplies commands to a utility 102 such as FDISK, or an early(version 3.0 or earlier) PartitionMagic program, or another knownpartition manipulation tool. The user 100 also receives information fromthe utility 102, such as partition type(s), location(s), and size(es),and the size and location of free space region(s). This information istypically provided through a Graphical User Interface (“GUI”); onesuitable GUI is illustrated in FIG. 6 of U.S. Pat. No. 5,675,769, andthat Figure and its accompanying text are incorporated herein. Withcontinued reference to FIG. 1, the utility 102 reads and (with propersemantic and syntactic constraints familiar in the art) writes apartition table 104 stored on a computer storage medium 106. The storagemedium 106 may include one or more hard drives, for instance. Thepartition table 104 defines the position, size, and type of one or morepartitions 108, which also reside on the storage medium 106, and maythus define one or more free space regions 110 as well. The utility 102also reads and writes (again, with proper constraints) file systeminformation and user data which are stored in the partition(s) 108 beingmanipulated.

Although the PartitionMagic program and other recently developed tools102 make partition 108 manipulation easier, faster, and safer than itwas with FDISK, there is still room for improvement. For instance, itwould be helpful to make experimentation easier so that users 100 canmore readily try different manipulations and select the ones they deembest. Implicit in this is the need to make it easier to undo a partition108 manipulation if the user 100 does not like the results. Programs 102could also provide more help in identifying the partition 108manipulations that will improve the performance or storage capability ofmedia 106 for a given computer.

One way to encourage experimentation is to make partition 108 moving andcopying operations even faster than before. This may be done, forinstance, by only moving user data that needs to be moved, as describedin claim 1 of the '769 patent identified above. However, this generalapproach is bounded by limits on the speed with which storage devices106 can move the user's data. A fundamentally different approach isneeded for additional manipulation speed improvements.

Another way to encourage experimentation (at least in theory) is to giveusers 100 a computer program development environment, to give themcomputer code for a program 102 implementing the manipulations, and toteach them enough about partitions 108, partition tables 104, filesystems in partitions, computers, programming, and the code to let themtry different approaches. A knowledgeable programmer can “comment out”or jump around sections of program 102 code that would otherwise executedisk 106 I/O or other operations in a given situation and then updatethe program's data structures using a debugger or other means to imitatethe omitted operation's results before the program 102 continuesexecution. In this way the effect of different operations on the program102 can be explored without necessarily performing the operations.

However, this approach has several serious drawbacks, not least of whichis the demand that users 100 manage a large body of complex technicalknowledge. Most users 100 do not have the technical tools required forthis approach. Moreover, users 100 want a reliable tool developed byskilled programmers so that the tool, not the user, manages theunderlying technical details. The fact that a highly knowledgeableprogrammer can achieve a certain result by making technicalmodifications to a program 102 does not enable most users 100 (or evenmost programmers) to obtain that result. This is particularly true ifthe program modifications needed also cripple the program 102 for itsnormal intended use.

In short, improvements are needed to promote experimentation andotherwise advance the art of partition manipulation. Accordingly, newsystems, devices, signals, and methods for manipulating partitions aredisclosed and claimed below.

BRIEF SUMMARY OF THE INVENTION

The present invention provides tools and techniques for simulating andperforming partition manipulations. By using the inventive simulator,users can experiment with “what if” scenarios, then “batch” all theirdifferent steps together. Prior to the invention, partitioning was astep-by-step process since each change to the disk needed to be appliedbefore additional changes could be made. The invention speeds up thepartitioning process, allowing users to manipulate the partitions todetermine the desired partition structure before actually applying thechanges. Users can now store multiple commands and execute them in asingle batch. This encourages users to experiment by making the resultsof virtual manipulations rapidly available to users. Batching alsoallows partition manipulation by way of lengthy operations on the actualdisk without requiring that a user be present to monitor the operationsor input the next command.

One aspect of the invention is a virtual engine environment which allowssimulation of partition manipulations to determine their effects beforeactually performing them. The virtual engine environment includesobjects which represent the hard disk structures in such a way that theycan be manipulated in multiple operations, and they retain theinformation necessary to perform calculations to determine the limits ofthe actual partitions. The virtual engine is also supported by a batchmanager which stores and otherwise manages the commands generated by thevirtual engine representing the operations to be performed on physicaldevice(s).

The virtual engine has the capability to model multiple operations onthe same or any number of partitions on the hard disk. The virtualengine environment can be initialized from the on-disk structures.Operations that the user may perform virtually include moving, resizing,creating, deleting, changing FAT properties (cluster size, rootdirectory entries), converting the partition from FAT to FAT32, NTFS,HPFS, or from FAT32 to FAT, setting the partition active,hiding/unhiding the partition, formatting, and retesting for badsectors. With one embodiment of the invention, users can: virtuallymanipulate partition structures for each of the disks in a computerwithout changing the on-disk state; generate a list of commands toperform all operations requested by the user without further userintervention; retain physical attributes of the virtual partitionsincluding total files and directories, cluster size, used space, freespace, wasted space, and file system parameters through multiple virtualoperations; and undo operations before committing the changes.

One embodiment of the invention helps eliminate unnecessary reboots andalso eliminates the need to reboot after each partition manipulation.One embodiment provides automatic handling of extended partitions, as itis able to make a primary partition from free space residing inside theextended partition, or make a logical partition out of free spaceresiding outside the extended partition. In addition, the invention letsusers make a drive read-only so that no changes may be made to thepartitions on that drive. The invention also lets users generate a listof user-modifiable commands from a list of virtual operations, andvice-versa.

Wizards are available through the invention to help users optimize freespace on a drive and within partitions by reducing cluster sizes and/orconverting to more efficient file systems, and to optimize move andresize operations to perform the minimal amount of data movingnecessary. A graphical or other user interface shows the before andafter state of the disk before the user commits the changes proposed bythe wizard. The wizard can also determine the optimal partition sizebased on a selected operating system, or let the user adjust the optimalsize.

Some wizard embodiments automatically add partitions to a boot manager,create the partition, and move other partitions to make room for the newpartition. Some embodiments automatically reduce cluster size or convertthe partition to a new file system to reclaim wasted space. Moregenerally, wizards analyze the user's disk configuration and recommendways to use the disk more effectively. The user may also set partitionconstraints, such as constraints on whether a given partition can bemoved or resized, and may set a minimum size to which the partition canbe resized. This places constraints on the algorithm that determineschanges to the partitions when creating a new partition, rebalancingfree space, or reclaiming wasted space, and preparing for a newoperating system. The invention adjusts logical partitions and/orprimary partitions to make room for a new operating system partition,and shrinks existing partitions just enough to make room for newpartitions created with the wizard. The invention also creates a primaryor a logical partition based on the context of the wizard operation.

A batch manager optionally optimizes the list of partition manipulationcommands by eliminating redundant operations (partition moves,creations, deletions, and so on). The batch manager keeps a persistent(on disk) list of commands representing virtual operations. It alsochecks the consistency of the partition before performing any changes,and optimizes out unnecessary checks between commands. Other featuresand advantages of the present invention will become more fully apparentthrough the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

To illustrate the manner in which the advantages and features of theinvention are obtained, a more particular description of the inventionwill be given with reference to the attached drawings. These drawingsonly illustrate selected aspects of the invention and thus do not limitthe invention's scope. In the drawings:

FIG. 1 is a diagram illustrating a conventional approach to partitionmanipulation.

FIG. 2 is a diagram illustrating tools and techniques for partitionmanipulation according to the present invention, including a virtualengine environment, a batch manager, a “real engine” for performingpartition manipulations, and other elements.

FIG. 3 is a diagram illustrating one of many possible computer networkssuitable for use in remote partition manipulations according to thepresent invention.

FIG. 4 is a diagram further illustrating the virtual engine environmentof FIG. 2.

FIG. 5 is a flowchart illustrating methods of the present invention.

FIG. 6 is a diagram illustrating a virtual partition signal according tothe present invention.

FIG. 7 is a diagram illustrating partition manipulations involving freespace inside an extended partition and a second partition outside theextended partition, which are performed to modify the second partitionafter moving some of the free space out of the extended partition.

FIG. 8 is a diagram illustrating partition manipulations involving freespace inside an extended partition and a second partition outside theextended partition, which are performed at least to bring the secondpartition inside the extended partition.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention relates to computer systems, methods, signals, andconfigured storage media for manipulating partitions. In particular, theinvention provides tools and techniques which allow users to simulatepartition manipulations in a virtual engine environment and, once thedesired commands are identified, to apply the manipulations to livepartitions on disk. The virtual engine environment gives users thefreedom to experiment with different partition manipulations withoutrequiring the overhead (incurred by unnecessary actual manipulations) ofprior approaches and without requiring lay users to become experts inthe underlying technology.

Some Definitions

For convenience, some of the terms used in this document are definedhere. However, these definitions must be viewed in the context of theentire document, and other terms are defined by examples giventhroughout the document.

The word “user” is sometimes limited in technical literature or otherdiscussions to human users of a computer system. However, in thisdocument “user” includes human users and/or computer processes acting onbehalf of human users.

“Memory” is occasionally used in the industry to refer to both internalmemory and to long-term storage. In this document, memory refers to theinternal memory which is typically used to hold program code and datawhile the program is running. Related but different items include“drives”, which were explained in the Technical Background, and “storagedevices”, which provide longer-term storage used to hold programs, userdata, and system data regardless of whether they are being used in acurrently-running program. Memory is typically RAM (Random AccessMemory), while familiar storage devices include magnetic disks andoptical storage media. Memory is often volatile where storage devicesare not, but memory can include non-volatile media such as ROM(Read-Only Memory), battery-backed RAM, and flash memory.

The words “command” and “operation” are sometimes used as synonyms inthe industry, but in this document “commands” are actions at the userinterface level, while “operations” are finer-grained and generally usedinternally in a manner which is not necessarily visible (or of directinterest) to users. One command may correspond to several operations, aswhen an “install a Windows NT operating system” command corresponds to amove or resize operation, a create operation, a format operation, and soon. In some cases, a command and an operation can be in one-to-onecorrespondence, as with a command to delete a specific file.

“Simulation” of a partition 108 or a drive providing a storage medium106 occurs in a computer. Simulation requires a model, such as a virtualpartition or a virtual drive, of the live partition 108 or live drivewhich is being simulated. A mere list of commands or operations alone isnot a simulation. Nor is it a simulation if one modifies a program 102(with or without access to the source code) that was written to do livepartition manipulations, temporarily disables disk I/O, and imitates theresults of that I/O by inserting numbers (e.g., with a debugger) beforeallowing execution to continue. This differs from simulation in that it(a) disables the live partition manipulation capability which ispresumably the program's main purpose, and (b) is not available toordinary users 100 because they lack one or more of the source code,debugger, knowledge of the program 102, and knowledge of the technicaldetails of partitions 108 and partition tables 104.

“Replication” includes copying or moving a partition 108. “Renaming”includes changing a drive letter or changing a volume label. “Hiddenstatus” of a partition 108 specifies whether the partition is hidden.“Active status” of a partition specifies whether the partition isactive. Only one partition on any given physical storage device may beactive at a time; the active partition is the bootable partition fromwhich the operating system is initialized. Replication, clusterresizing, and file system type conversion assume the partition has beenformatted; all other operations do not assume previous formatting.

Architectural Overview

One technological predecessor of the present invention is thePartitionMagic® 3.0 partition manipulation program, which iscommercially available from PowerQuest Corporation of Orem, Utah (“PM3.0”). Like many other partition manipulation tools 102, PM 3.0 may beviewed as having two parts, namely, a user interface and an engine, withthe user interface residing on top of (i.e., closer to the user 100than) the engine.

By contrast, as shown in FIG. 2 one embodiment of the present inventionincludes a user interface 200 (containing a platform-specific userinterface 202 and a common user interface 204 discussed below), avirtual engine environment 206 (denoted generally as the “VirtualEngine” in the '982 and '213 applications), a batch manager 208, a “realengine” 210, and one or more wizards 212. These components, and theircorresponding methods and signals, are discussed in greater detailbelow.

Virtual Engine Environment

The virtual engine environment 206 allows users 100 to simulate theeffects of partition 108 manipulations without necessarily committingthemselves by actually performing the manipulations on the disk 106.Once a desired sequence of commands is identified by the user 100, thebatch manager 208 creates a corresponding sequence of operations andfeeds them to the real engine 210, which actually performs themanipulations on the storage medium 106. Thus, users 100 can investigatethe likely results of different command sequences without waiting foreach command sequence to actually be carried out on disk. Moreover,technical details are managed by the virtual engine environment 206, thebatch manager 208, and the real engine 210, so users 100 need not betechnical experts in order to manipulate partitions 108 safely andefficiently.

The virtual engine environment 206 includes a virtual engine 400 andsupporting structures such as virtual disk drives 402 and virtualpartitions 404. The virtual engine 400 operates on virtual structures tosimulate the effects of corresponding operations by the real engine 210on the real storage medium 106 and its contents, including the realpartition table 104 and the real partitions 108. Real on-disk structuresare also referred to herein as “live” structures, e.g., live partitions108. The virtual engine environment 206 is discussed further inconnection with FIG. 4 and elsewhere herein.

User Interface

The platform-specific user interface (“PSUI”) 202 and the common userinterface (“CUI”) 204 modules may be implemented such that the PSUI 202is local on each client in a network, the CUI 204 is on a server, andthe clients and server communicate over a communication link. Thisallows one live engine 210 and/or one live engine 210—virtual engine 400pair to serve multiple clients even when each client uses a differentplatform. For instance, one client might be a diskless node runningLINUX, while another is a workstation with a local disk which is runninga Windows brand operating system. Interface modules, such as Javamachines and/or computer networking modules (software and hardware) maybe added to connect the PSUIs 202 and the CUI 204. Note that disklessnodes have no local disks, and hence no live local partitions, but cannonetheless be used as simulation platforms to perform virtual partitionmanipulations.

The platform-specific user interface 202 is tailored to Windows NT,Windows 95, Windows 98, Windows 2000, DOS TTY, Linux, or othertext-oriented or graphical user interface environments (WINDOWS NT,WINDOWS 95, and WINDOWS 98 are marks of Microsoft Corporation). Thecommon user interface 204 contains user interface structures andfunctions common to two or more platforms. In alternative embodiments,the common user interface 204 is omitted, so that only a version of theplatform-specific interface 202 is present. User interfaces in generalare well-known in the art, but some of the functionality presentedthrough the user interface 200 is specific to the present invention,such as the ability to interface with a virtual engine environment 206and the ability to commit virtual engine operations by passing them to areal engine 210 for execution.

The CUI layer 204 may be implemented as a higher level applicationprogram interface (“API”) to the virtual engine 400. The CUI 204 makesusage of the virtual engine 400 easier for multiple interfaces(text/tty, GUI, scripting, . . . ) and provides remotability benefits aswell. In one embodiment, the CUI layer 204 includes a set of classes,each of which pertains to a specific operation such as Delete Partition,Create Partition, and so on. These classes encapsulate almost all thefunctionality required by an interface but not provided by the partitionmanipulation portions of the virtual engine environment 206. Forexample, when deleting a partition, the interface 200 displays thecurrent label and has the user 100 confirm the partition deletion byentering the label and verifying that it is correct. The CUI 204 classfor the delete operation provides an API to get the label and handlesthe label verification before calling on the virtual engine 400 todelete the partition. The CUI layer 204 also provides APIs that are morein the user's context than the engine's, such as getting sizeinformation on a partition in Megabytes rather than a number of sectors.

One of the key design rules of the CUI layer 204 is that it shields theusers 100 from the underlying structures and complexity of the virtualengine environment 206. For instance, pointers to environment 206structures are rarely used in the CUI layer 204 API. In general, onlythe most basic types are used (int, double, char, and so on). This isparticularly important and useful when remoting the interface.

For instance, consider the task of getting the partition 404 label. Inorder to accomplish this the virtual engine 400 first needs a pointer toa partition 404 or volume structure; this might be obtained through adrive object 402 pointer which is obtained from the environment 206. Thesystem might then call a GetLabel function on the FileSystem object 408of the partition 404: vol->GetFileSystem( )->GetLabel( ). The CUI 204Classes encapsulate selection of a specific partition and present aGetLabel( ) function. The user 100 does not need any knowledge of a filesystem object, or even a volume/partition object. Volumes or partitionsare selected using an integer index value. This encapsulation alsoallows the platform-specific user interface portion 202 of the code tobe much smaller, since all common functionality used by the differentinterfaces resides in one place.

Another advantage of using basic types is the ease of using theinterface 200 remotely. With the CUI 204 classes, it becomes very easyto put a COM (Microsoft's Component Object Model) interface over the CUI204 without worrying about marshaling issues (one can use the IDispatchinterface). The platform-specific user interface 202 can then reside onthe same machine, or a different machine using DCOM (Distributed COM).It is also easier to remote when working with languages other than C++because it is easier to write wrappers around the CUI 204 (and thus thevirtual engine 400) for languages like Java.

Wizards

A wizard 212 is basically a tool that asks questions and provides a listof common answers from which the user 100 can select. The chosen answersare then used to automate the asked-for function.

A novice user such as user A in FIG. 2 may be guided through commonpartition manipulations by one or more wizard utilities or tutorials.More experienced users, such as user B, may bypass the wizards 212 andaccess the user interface 200 directly. Wizards and tutorials generallyare well-known in the art, but are novel in the context of the presentinvention.

Batch Manager

The virtual engine 400 is supported by the batch manager 208, whichstores the commands generated by the virtual engine 400. These commandsrepresent the operations to be performed on the physical device(s) 106.In some embodiments, the batch manager 208 can optimize the storedcommand lists to reduce the time or effort that would be required by thereal engine 210 to execute the command list. Before allowing the realengine 210 to execute a command list, the batch manager 208 also ensuresthat the real disk 106 is in the same state as it was when the commandlist was created in the virtual engine environment 206, so that userdata is not damaged or destroyed (unless the user requested filedeletion, for instance).

During efforts that eventually led to the present invention, an attemptwas made to support “batching” or a list of multiple commands to beexecuted in a real engine without a distinct virtual engine environment206. However, modifying the real engine in an ad hoc manner to implementbatching inside it caused confusion arising from multiple code paths andother problems. By contrast, the virtual representation 400 of the realengine 210 can be used independently of the actual operations and realengine structures on the physical disk 106 and provides the otheradvantages discussed herein.

Real Engine

The real engine 210 carries out partition 108 manipulations on thestorage medium 106. The real engine 210 may be a novel engine. Forinstance, the real engine 210 might be tightly integrated with thevirtual engine environment 206 and/or the batch manager 208. The realengine 210 could also be novel in the sense that it implements featuresclaimed in one or more commonly owned copending patent applicationsidentified above. However, the real engine 210 may also be aconventional utility 102, perhaps with minor modifications to acceptcommands from the batch manager 208 in addition to (or instead of)accepting them directly from users 100. For instance, the PM 3.0 engineis an example of a real engine 210 which performs partition 108manipulations on the hard disk or other storage device 106.

Computers and Networks Generally

FIG. 3 illustrates a network 300 which is one of the many possiblenetworks suitable for adaptation and use according to the presentinvention. The network 300 may be connectable to other networks 302,including LANs or WANs or portions of the Internet or an intranet,through a gateway or similar mechanism, thereby forming a larger networkwhich is also suitable for use according to the invention.

The illustrated network 300 includes a server 304 connected bycommunication links or network signal lines 306 to one or more networkclients 308. Other suitable networks include multi-server networks andpeer-to-peer networks. The server(s) 304 and client(s) 308 in aparticular network according to the invention may be uniprocessor,multiprocessor, or clustered processor machines. The server(s) 304 andclient(s) 308 each include an addressable storage medium such as randomaccess memory.

Suitable network clients 308 include, without limitation, personalcomputers; laptops 310, personal digital assistants, and other mobiledevices; and workstations 312. The signal lines 306 may include twistedpair, coaxial, or optical fiber cables, telephone lines, satellites,microwave relays, modulated AC power lines, RF connections, a networklink, a dial-up link, a portable link such as an infrared link, and/orother data transmission “wires” or communication links known to those ofskill in the art. The links 306 may embody conventional or novelsignals, and in particular, may embody a novel series of commands and/ordata structures in a virtual engine environment 206 as discussed herein.

The server(s) 304 and/or client(s) 308 may include a non-volatileprogram storage medium such as a magnetic or optical disk, ROM, bubbleor flash memory. The program storage medium may be part of the samestorage medium 106 that holds partition structures 104, 108, or it maybe a separate medium. That is, a computer program according to theinvention may be run from the storage medium 106 that the programmanipulates, or the program may be run from one medium and manipulatepartitions 108 on another medium, or both. A suitable program storagemedium includes a magnetic, optical, or other computer-readable storagedevice having a specific physical configuration. Suitable storagedevices include floppy disks, hard disks, tape, CD-ROMs, PROMs, randomaccess memory, ROM, flash memory, and other computer system storagedevices, configured according to the present invention.

The physical configuration represents data and/or instructions whichcause the computer system 300 to operate in a specific and predefinedmanner as described herein. Thus, the program storage medium tangiblyembodies a program, data, functions, and/or instructions that areexecutable by servers and/or other computers to provide and/or use avirtual engine environment 206 substantially as described herein.Suitable software and hardware implementations according to theinvention are readily provided by those of skill in the art using theteachings presented here and programming languages and tools such asJava, Pascal, C++, C, assembly, firmware, microcode, PROMS, and/or otherlanguages, circuits, or tools. On issuance of a patent based on thisdocument, the public may also view source code examples directly in thisdocument and in the incorporated '213 application.

When multiple computers in the system 300 are used, the common userinterface 204 provides optional but generally positive benefits. Forinstance, commands may be sent from a first computer, e.g., the server304, over a link 306 to an engine on a remote second computer, e.g., oneor more of the clients 308. The server 304 and the client 308 mayprovide different platforms, e.g., Linux on the server 304 and Windows95 on the client 308, with at least a corresponding platform-specificuser interface 202 on the server 304 and at least an instance of thecommon user interface 204 on the client 308. In one configuration, thevirtual engine environment 206 being used resides on the server 304 andthe real engine 210 which eventually may carry out commands from theserver 304 resides on the client 308 whose partition(s) 108 will bemanipulated. In another configuration, the platform-specific userinterface 202 on the server 304 communicates over a link 306 with aninstance of the common user interface 204 and hence with a virtualengine environment 206 on the client 308; the real engine 210 whicheventually may carry out commands from the server 304 likewise resideson the client 308.

Virtual Engine Environment

FIG. 4 further illustrates the virtual engine environment 206.Discussion of this Figure begins with an overview of the componentfunctionality and structural relationships involved, and then proceedsinto greater detail of the individual components.

The virtual engine environment 206 allows users to simulate the resultsof various partition commands without necessarily performing thosecommands by live partition manipulation, thereby easing and encouragingthe exploration of alternative disk organizations. The virtual engineindicated at 400 is a representation of the “real” software engine 210,which can be used independently of actual operations on the physicaldisk or other medium 106.

As used here, “virtual partition” means a model of a partition 108,which is typically kept in memory during use. By contrast, “livepartition” means the actual partition 108 on the storage device 106.Changing a virtual partition 404 does not necessarily change thecorresponding live partition 108, and vice versa. The word “performing”as used here means operating on a live partition 108 on the storagedevice 106, as opposed to a virtual operation on a virtual partition404.

As shown in FIG. 4, the virtual engine environment 206 include a set ofobjects stored in memory which represent the hard disk 106 structures insuch a way that multiple operations can be simulated with the endvirtual result being the “same” as if the commands were performed on thereal structures. Information is kept in the virtual partition objects toenable the virtual partition 404 to be virtually moved and resized,while retaining the file system information governing total sectors usedin the aggregations of files and file system structures.

The list of operations and the virtual engine environment 206 datastructures may be stored as user data on the storage device 106 oranother medium such as the program storage medium discussed above. Theoperations list and data structures may be stored either (a) indirectlywhen memory is paged out, or (b) directly by the inventive software toaid recovery in case of a power failure or other interruption. Thediscussions of recovery partition indicators and data recovery methodsfrom the '769 and '472 patents are incorporated herein by thisreference.

The simulation supported by the virtual engine environment 206 is not amere list of commands for a computer to perform. Rather, it requires amodel of the system to be simulated: in this case the model begins as anidentical version of the current disk partition 108 characteristics keptin memory. Changes made to virtual partitions 404 will therefore mirrorchanges made to the live partitions 108 without modifying the realsystem on the medium 106. For example, the limits of the actualpartitions 108 would be the same in the virtual system and the realsystem. In the rest of this section, unless otherwise stated, allchanges made to the system 300 are virtual changes but correspondingphysical changes may be made to partitions 108 and the partition table104 on the storage medium 106.

The virtual engine environment 206 embodies familiar rules of partitionmanagement, such as: each logical partition must be inside an extendedpartition; extended partitions cannot be arbitrarily nested;non-extended partitions may not overlap; an IBM-compatible drive mayhave at most four primary partitions; logical partitions must be“notched”; partitions must end on a cylinder boundary; and so forth.Compliance with these rules is generally assumed by operating systems;if the rules are not followed, user data may be corrupted or lost. Ofcourse, part of the benefit of using a virtual engine is that if youmake a virtual mistake you don't also make a “real” mistake.

All changes in the virtual structures can be undone (discarded) byre-initializing the virtual structures so they once again matchvalue-for-value the on-disk structures used by the real engine 210. Insome embodiments, the virtual engine environment 206 may be bypassed(either by a local user or by remote access over a link 306), allowingdirect access to the real engine 210 if the user so desires. In thiscase, changes cannot be so readily undone.

Using the virtual engine environment 206, multiple operations can besimulated on any number of partitions 404. Operations that the user 100may perform virtually include the following: creating a formattedpartition 404; deleting a partition 404; moving an existing partition404; moving a newly created partition 404; copying a live partition 108or another virtual partition 404 to a virtual partition 404; resizing anexisting partition 404; resizing a newly created partition 404; changingattributes of the file system virtually, such as the FAT cluster sizeand the root directory entries; converting a partition 404 from one typeto another, such as from FAT to FAT32, NTFS, HPFS, or from FAT32 to FAT,and so on; getting information about live partitions 108 and/or virtualpartitions 404; changing the volume label on a partition 404;hiding/unhiding a partition 404; formatting; and testing or retestingfor bad sectors.

An undo feature allows the user 100 to undo the virtual operationsbefore committing to the changes to the real engine 210. Furthermore,the virtual engine environment 206 gives the user 100 the ability toautomatically resize extended partitions 404 when primary or logicalpartitions 404 cross their boundary, or delete extended partitions 404if a primary partition 404 is resized such that it completely covers theextended partition 404. The virtual engine environment 206 can alsochange the “active status” of a partition 404. Only one partition 108 onany given physical storage device may be active at a time; the activepartition 108 is the bootable primary partition 108 from which theoperating system is initialized.

As noted, the virtual engine environment 206 includes the virtual engine400. The virtual engine 400 is discussed directly or by implicationthroughout this document; it is a major component of the virtual engineenvironment 206 which simulates the real engine 210.

C++ include files which define functions and structures used in animplementation of the invention (and other information as well) areincluded even though current law does not mandate the inclusion ofsource code when it exists. Those of skill will understand thatcorresponding *.cpp files may be readily implemented in various ways,that other implementations of the *.hpp file structures shown may alsoembody the invention, and that the invention may be implemented usingprogramming languages other than (or in addition to) the C++ language.Bearing this in mind, one embodiment implements the virtual engine 400using a C++ class such as the following, which is a condensed revisionof the class described in the '213 application:

class VEngine { public: VEngine ( ); ˜VEngine ( ); PQRET Init( ULONGFlags, char *CmdLine, int argc, char *argv[ ], UINT CodePageType, ULONG*ulInProg, // Operation in progress, (probably power failure) int Debug,BOOL Demo = FALSE); PQRET InitDrives ( ); PQRET UnInit( ); VDrive*GetDrive (ULONG ordinal); BOOL BatchPending( ); BOOLCanCommitChangesLive ( ); PQRET CommitChanges ( ); USHORT GetNumDrives (); ULONG GetLargestFreespace ( ); void SetLegalOps ( ); ULONGGetNextPartitionID( ); BOOL AreAllPartitionsFATorFAT32 ( ); PQRETReadPreferences ( ); PREFERENCES *GetPreferences ( ); virtual BOOLIsFat32Supported(BOOL *isSupported) // Boot Manager Functions BOOLBMCanSetPrefs ( ); BOOL BMCanAdd(VPartition *pPartition); BOOLBMCanChangeName (VPartition *pPartition); BOOL BMCanInstall (VPartition*pPartition); BOOL BMCanBeDefault (VPartition *pPartition); BOOLBMCanRemove (VPartition *pPartition); BOOL BMIsDefault (VPartition*pPartition); PQRET enIsBootManagerPresent ( ); PQRETenInstallBootManager VPartition *pi, // Partition to install in UCHARucPosFlag); // Position flag #define BM_POS_BEGIN 0 // Specifies BM tobe positioned at the start of free space #define BM_POS_END  1 //Specifies BM to be positioned at the end of free space PQRETenAddToBootManager( // Add partition VPartition *pi, // Partition to addchar *name); // Name of partition in menu PQRETenChangeBootManagerEntry( VPartition *pi, // Partition to change char*name); // Name of partition in menu PQRET enSetBootManagerDefault( //Set the default partition for Boot Manager VPartition *pi); PQRETenRemoveFromBootManager( VPartition *pi); // Partition to be removed //Wizard functions ULONG CalcWastedSpace ( void ); PQRET WizConvertFat32 (void ); // Batch manager functions PQBatchMgrBuild *GetBatchMgrBuild (); PQBatchMgrExec *GetBatchMgrExec ( ); BOOL GenDriveMapperCmds ( ); //Drive Letter Calculation Functions BOOL CanChooseDriveLetter ( ); voidAssignDriveLetter (VPartition *NewPartition, char DriveLetter); voidResetDriveLetters ( ); void GetAvailDriveLetters(char *LetterArray,VPartition *pDest, VLimits *pLimits); char GetNextDriveLetter(VPartition *pDest); void BuildDriveLetterList(VDriveLetterList &List,OS_TYPE os, VLimits *pLimits) void RemoveDriveLetter(char Letter); //Partition Functions VPartition *GetFirstPartition ( ); VPartition*GetNextPartition (VPartition *partition); // Operating SystemInformation OS_TYPE GetOS ( ); BOOL CanMountPartition(PART_TYPEpartType); BOOL IsRebootRequired(void), UINT GetOrigDriveType (USHORTDriveLetterIndex) { return DriveTypes[DriveLetterIndex]; } protected:void LinkDriveToEnd(VDrive *pDrive); void LinkDriveAfter(VDrive *pDrive,VDrive *pAfter); VDrive *DriveList; PQBatchMgrBuild *BatchMgrBuild; //batch manager (for the “Build List” side of things) PQBatchMgrExec*BatchMgrExec; // batch manager (for the “Execute List” side of things)ULONG NTDriveLetterBits; // Drive letter flags from WinNT UINTDriveTypes[MAX_DRIVE LETTERS]; UCHAR CDROMFirstDrive[MAX_DRIVE_LETTERS];// First drive settings for CDROM drive letters ULONG PartitionID; BOOLbRebootRequired; // reboot will happen on exit of application };

As noted above, the virtual engine environment 206 includes one or morevirtual drives 402 which model actual drives holding partitions 108. Thevirtual drive(s) assign drive letters (e.g., “C:”) according to theconventions used by the DOS and Windows operating systems. In addition,drive geometry is modeled by one drive geometry structure 406 for eachvirtual drive 402. As used here, “drive geometry” refers to low-leveldrive characteristics such as the number of cylinders, heads, andsectors per track on a physical drive which is being modeled in thevirtual engine environment 206. One embodiment includes a C++ class suchas the VGeometry class shown in the '213 application.

In one embodiment, virtual drives 402 are implemented using a C++ classsuch as the following, which is a condensed revision of the classdescribed in the '213 application:

class VDrive { public: VDrive (VEngine *engine, DISK_INFO *di); ˜VDrive( ); PQRET Init ( ); PQRET UnInit ( ); void SetLegalOps ( ); // UserInterface Display Information VPartitionDisplayInfo *GetDisplayList ( );USHORT GetNumUlVolumes ( ); VPartition *GetUIVolume (USHORT Index); //Wizard Functions BOOL WizGetFreeSpace ( BOOL IsPrimary, ULONGLogicalLimit, FS_TYPE FileSystemType, ULONG &Min, ULONG &Max, ULONG&Recommend ) ; BOOL GetFreeSpaceDisplayList( BOOL IsPrimary, ULONGLogicalLimit, FS_TYPE FileSystemType, ULONG NewPartitionSize, char*NewLabel, VPartitionDisplayInfo **PartList ); PQRET WizCreatePartition( BOOL IsPrimary, FS_TYPE FileSystemType, ULONG NewPartitionSize, char*NewLabel ); BOOL GetBalanceLevel ( int& ); BOOL GetReBalanceDisplayList( VPartitionDisplayInfo **pFirstDisPart ); PQRET WizReBalanceFreeSpace(void ); ULONG CanOptimizeClusterSize ( VPartitionDisplayInfo **PartList,ULONG &TotalWasted ); PQRET WizOptimizeClusterSize( void ); BOOLMainGetFreeSpace( BOOL IsPrimary, ULONG LogicalLimit, FS_TYPEFileSystemType, ULONG NewPartitionSize, ULONG &Min, ULONG &Max, ULONG&Recommend, VPartitionDisplayInfo **pFirstDisPart, char *NewLabel, intFuncType ); ULONG GetMax (VPartitionDisplayInfo *pFirstPart, ULONGLogicalLimit, FS_TYPE fsType); ULONG GetRecommended(VPartitionDisplayInfo *pFirstPart, ULONG LogicalLimit, FS_TYPE fsType);// Wizard Support Functions ULONG GetMax (VPartitionDisplayInfo*pFirstPart, ULONG LogicalLimit); ULONG GetMin(VPartitionDisplayInfo*pFirstPart); ULONG GetRecommended (VPartitionDisplayInfo *pFirstPart,ULONG LogicalLimit); // Partition Support Functions PQRETCreatePartition(VPartition *pDest, VLimits *pLimits); voidAddFreeSpacePartitions (BOOL bDeleteFree = FALSE); PQRET Copy(VPartition*pSource, VPartition *pDest); PQRET DeletePartition (VPartition*pPartition); // Master Boot Record (“MBR”) Functions BOOL IsMbrFull (); USHORT GetNextAvailMbrOrdinal ( ); // Partition query functionsVPartition *GetExtended ( ); VPartition *GetFirstPartition ( ); // DriveGeometry Functions VGeometry *GetGeometry ( ); USHORT GetCylinders ( );USHORT GetHeads ( ); ULONG GetSectorsPerCylinder ( ); USHORTGetSectorsPerTrack ( ); ULONG GetBytesPerSector ( ); ULONGGetOSSectorBoundary ( ); ULONG GetDiskSize ( ); USHORT GetDriveNumber (); // Linked List functions VDrive *GetPrev ( ); VDrive *GetNext ( );void SetNext(VDrive *pDrive); void SetPrev(VDrive *pDrive); // CylinderRounding Functions ULONG RoundSizeToCylinder ( ULONGulSectsFirstCylinder, ULONG ulNumSects, ROUND_METHOD rmRound); //ROUND_UP, ROUND_DOWN, or ROUND_CLOSEST ULONG RoundPosToCylinder ( ULONGulSectsFirstCylinder, ULONG ulStartSect, ROUND_METHOD rmRound); ULONGRoundSectorToCylinder (ULONG ulSectorNumber, ROUND_METHOD rmRound);ULONG Get1024CylinderBoundary ( ); void Set1024CylinderBoundary(ULONGulsectPast1024); BOOL IsReadOnly ( ); // Parent Access VEngine*GetEngine ( ); DISK_INFO *GetDI ( ); BOOL HaveDriveMappingsChanged(BOOLbGenerateCmds); BOOL AreAllPartsFATorFAT32 ( ); // Linking Functionsvoid UnlinkPartition (VPartition *pPartition); void LinkPartitionToEnd(VPartition *pPartition); void LinkPartitionAfter (VPartition*pPartition, VPartition *pAfter); void LinkPartition(VPartition*pPartition); // Links the Partition in order of startsector protected:// Data members VEngine *Engine; VDrive *Prev; VDrive *Next; VPartition*PartitionList; DISK_INFO *DiskInfo; USHORT usDriveNumber; // GeometryVGeometry Geometry; ULONG ulTotalSectors; ULONG ulOSSectorBoundary;ULONG ul1024CylinderBoundary; // first sector past the 1024 cylinderboundary (FAT only) };

Several copies of information about a given partition 108 may exist,including the virtual partition 404 and related structures in thevirtual engine environment 206; the actual, governing structures locatedon the disk 106 (and possibly copied into operating system or filesystem memory as well), and a copy of the on-disk structures in memoryfor use by the real engine 210. In addition, the user interface 200 mayhave a set of display objects, which are a functional subset of thevirtual partition 404, virtual file system and similar objects used bythe virtual engine environment 206. Display objects can be used, forinstance, to show the effects of rebalancing free space without invokingthe fill virtual engine environment 206.

In one embodiment, virtual partitions 404 are implemented using a C++class such as the following, which is a condensed revision of the classdescribed in the '213 application:

class VPartition { public: VPartition( VDrive *drive, USHORTmbrEntryOrdinal, VMbrEntry *entry, PART_CLASS PartClass, BOOL isVirtual= TRUE); ˜VPartition ( ); PQRET Init(PARTITION_INFO *pi); //Initializing from disk PQRET InitFree ( ); // Initializing VirtuallyPQRET UnInit ( ); // Interface functions PQRET Adjust(VLimits *pLimits,BOOL bAddFree = TRUE); PQRET ChangePartition(VLimits *pLimits, BOOLHidePartition = FALSE); PQRET ChangePartition(FS_TYPE fsType, void*label, UINT labelLength, UINT uiLabelType); PQRET ConvertTo(FS_TYPEfsType); PQRET Format(FS_TYPE fsType, void *label, USHORT labelLength,USHORT uiLabelType); PQRET Hide(BOOL BatchThisCommand = TRUE);   PQRETUnHide ( ); PQRET SetActive ( ); // Access to File System VFileSystem*GetFileSystem ( ); // Limits Calculation and Initialization VLimits*GetLimits(BOOL bGetDetailedLimits = FALSE); // UI Flags Access ULONGGetUIFlags ( ); // Partition State Information BOOL IsBootable ( ); BOOLIsExtended ( ); BOOL IsLogical ( ); BOOL IsHidden ( ); BOOL IsVirtual (); BOOL CanBeCopyDest (VPartition *pSource); // Partition InformationPART_CLASS GetPartitionClass ( ); PART_TYPE GetPartitionType ( ); ULONGGetStartSector ( ); ULONG GetEndSector ( ); ULONG GetSectorCount ( );USHORT GetMbrEntryOrdinal ( ); ULONG GetSectorsOn1stCylinder ( ); ULONGGetNotchSectors ( ); FS_TYPE GetFSType ( ); char *GetPartitionTypeName (); PARTITION_INFO *GetPI ( ); ULONG GetPartitionID ( ); BOOLIsTypeVisibleToOS (OS_TYPE os = OS_VER_UNKNOWN); void SetLegalOps ( );void ClearBootFlag ( ); // Functions to calculate limits around thisPartition ULONG GetMinLeftEdgeBoundary(BOOL Recursing = FALSE); ULONGGetMaxRightEdgeBoundary(BOOL Recursing = FALSE); // Access to ParentDrive VDrive *GetDrive ( ); // Linked List Functions VPartition *GetNext( ); VPartition *GetPrev ( ); void SetNext (VPartition *pPartition);void SetPrev(VPartition *pPartition); // Translation from FileSystem toVOLUME_TYPE VOLUME_TYPE GetVolType ( ); // Make the Partition virtual -call this when any changes // are made that disallow the Partition fromreading information from the on-disk Partition void MakeVirtual ( ); //Set Functions void SetMbrEntryOrdinal (USHORT Ordinal); protected: BOOLIsPartKnownHidden ( ); void SetUIFlag(ULONG flag); voidClearUIFlag(ULONG flag); PQRET CreateFileSystem(FS_TYPE fsType, chardriveLetter = ‘*’, void *label = NULL, UINT labelLen = 0, UINT labelType= 0); BOOL LimitsOverlap (VLimits *pLimits); PQRET ResizePartitionEntry(VLimits *pLimits); // Partition Data VDrive *Drive; PARTITION_INFO*PartInfo; USHORT MbrEntryOrdinal; // mbr table Index; −1 if freeSpaceVNbrEntry *MbrEntry; VFileSystem *FileSystem; PART_CLASS PartClass; //PART_CLASS_PRIMARY,PART_CLASS_EXTENDED,PART_CLASS_LOGICAL ULONG UIFlags;BOOL bIsVirtual; ULONG ulSectorsOn1stCylinder; ULONG PartitionID; //Unique to this virtual Partition // Linked List members VPartition*Prev; VPartition *Next; };

As illustrated in FIG. 4, the virtual engine environment 206 alsoincludes a virtual file system 408 which models file systems generally,and more detailed structures such as a virtual FAT file system 410 whichmodel partition-manipulation-related aspects of specific file systems.Other structures 410 model NTFS, HPFS, LINUX, and other file systems.The possible virtual file systems 408 include a “file system” whichmodels an unformatted partition 108, for conveniently distinguishingfree space outside partitions 108 from space that is allocated topartitions 108 but is not necessarily used (allocated to files or systemstructures) within the surrounding partition 108.

In one embodiment, virtual file systems 408 are implemented using a C++class such as the following, which is a condensed revision of the classdescribed in the '213 application:

class VFileSystem { public: VFileSystem(VPartition *Partition, chardriveLetter, FS_TYPE fsType); virtual ˜VFileSystem ( ); virtual PQRETInit(PARTITION_INFO *i = NULL); // Interface Functions virtual PQRETCheck ( ); virtual PQRET ConvertFileSystem(VFileSystem *OldFileSystem);virtual ULONG GetFreeSectors ( ); virtual ULONG GetUsedSectors ( );virtual PQRET RetestBadSectors ( ); virtual char GetDriveLetter ( );virtual void SetDriveLetter(char letter); virtual PQRETSetVolumeLabel(void *label, int iBufLen, UINT uiLabelType = CP_DOS);virtual PQRET Adjust (VLimits *pLimits); // Access to original driveletter char GetOldDriveLetter ( ); PQRET Mount ( ); PQRET UnMount ( );// Wizard Functions void SetConstraints(ULONG ulFlags, ULONG ulValue);void GetConstraints(ULONG &ulFlags, ULONG &ulValue); voidClearConstraints ( ); BOOL IsConstraintsLegal ( void ); BOOLCanConvertFatToFat32 ( ULONG &SavedSector, VPartitionDisplayInfo*pFirstDisPart ); BOOL WizConvertFatToFat32 ( void ); // Limit functionsvirtual VLimits *GetLimits(BOOL bGetDetailedLimits = FALSE); // UI voidSetLegalOps ( ); virtual BOOL CanCheck ( ); virtual BOOL CanCheckInfo (); virtual BOOL CanCopy ( ); virtual BOOL CanDeFrag ( ); virtual BOOLCanFormat ( ); virtual BOOL CanFormatAs(FS_TYPE fsType); virtual BOOLCanMove ( ); virtual BOOL CanResize ( ); virtual BOOL CanResizeRoot ( );virtual BOOL CanRetestBadSectors ( ); virtual BOOL CanSetLabel ( );virtual BOOL CanConvertHPFS ( ); virtual BOOL CanConvertTo(FS_TYPEfsType); virtual BOOL CanCheckNative ( ); // File System Informationvirtual FS_TYPE GetFSType ( ); virtual PQRET GetBadMBRError ( ); virtualBOOL CheckFailed ( ); virtual PQRET GetInfo(ALL_INFO *ai); virtual PQRETGetCheckInfo(ALL_CHECK_INFO *ci,ULONG ulPref); ULONGGetEstimatedFilesAndDirs ( ); void SetEstimatedFilesAndDirs (ULONGulFilesandDirs); virtual USHORT DeterminePartitionType ( ); virtualULONG GetSerialNumber ( ); // File System Cloning Function - Used forCopy operation virtual void CopyFileSystem(VFileSystem *fsSource); //Volume Label Functions virtual PQRET GetVolLabel(void *label, intiBufLen, UINT *uiLabelType = NULL, int *iRetBufLen = NULL); virtualVOL_LABEL GetVolLabel ( ); virtual void SetVolLabel(void *label, intiBufLen, UINT uiLabelType); // Access to parents VPartition*GetPartition ( ); protected: void SetUIFlag(ULONG flag); voidClearUIFlag(ULONG flag); virtual BOOL CanFatResizeRoot ( ); ULONGGetMinFSSize(FS_TYPE fsType); ULONG GetMaxFSSize(FS_TYPE fsType);VPartition *Partition; // Parent object // File System Constraints ULONGulConstraintFlags; ULONG ulConstraintValue; // Percent or number ofsectors // File System Data VOL_LABEL Label; char OldDriveLetter; charDriveLetter; FS_TYPE FSType; ULONG ulEstFilesAndDirs; // Estimated # offiles & dirs ULONG UIFlags; ULONG ulSerialNumber; ULONG ulUsedSectors;ULONG ulFreeSectors; BOOL bCheckFailed; };

In one embodiment utilizing C++ objects, a virtual limit object 412(corresponding to a given virtual partition object 404 and matchingvirtual file system 408 object) is created when virtual partition 404manipulations are begun. In conjunction with a file-system-specificlimits object 414, the virtual limit object 412 encapsulates limits suchas the left and right boundaries of the virtual partition 404, the sizeof the virtual partition 404, the requirement that the partition 404boundary be a disk cylinder boundary, the partition 404 “class”(primary, logical, or extended; not to be confused with a C++ class), anindication whether the partition 404 is formatted, the volume label ifany, which file system types are available if the partition object 404represents unformatted space on the medium 106 and which file systemtype is present if the partition object 404 represents a formattednon-extended primary or formatted logical partition 108.

File system availability depends on which file systems havecorresponding virtual file system definitions (e.g., definition 410 forFAT file systems) in the implementation of the virtual engineenvironment 206 and on the size of the virtual partition 404. Forinstance, some FAT partitions 108 have a maximum size of 2 Gigabytes,LINUX swap partitions 108 have a maximum size of 128 Megabytes, FAT32partitions 108 must be at least 256 Megabytes in size, and so on.Definitions analogous to the FAT file system definition 410 are readilyprovided for NTFS, HPFS, LINUX/EXT2, FAT32, various other FAT, and otherfile systems. An implementation may use default values for partitionsize (largest possible), partition class (FAT), and partition formattingstatus (unformatted). “FAT” refers collectively to all FAT file systems,including FAT12, FAT16, and FAT32 file systems.

Virtual limit objects 412 may be implemented using a C++ class such asthe following, which is a condensed revision of the class described inthe '213 application:

class VLimits { public: VLimits (VPartition *Partition); virtual˜VLimits ( ); PQRET Init ( ); ULONG GetMaxStartSector ( ); ULONGGetMinStartSector ( ); ULONG GetStartSector ( ); virtual voidSetStartSector(ULONG ulSect, BOOL bResize); ULONG GetMaxEndSector ( );ULONG GetMinEndSector ( ); ULONG GetEndSector ( ); virtual voidSetEndSector(ULONG ulSect, BOOL bResize); ULONG GetMaxSize ( ); ULONGGetMinSize ( ); ULONG GetSize ( ); UINT64 GetSizeBytes ( ); virtual voidSetSize(ULONG ulSize); virtual ULONG CalcMaxSize(ULONG minStartSect,ULONG maxEndSect); virtual ULONG CalcMinSize ( ); ULONGGetUsedinExtended ( ); FS_TYPE GetFSType ( ); virtual PQRETSetFSType(FS_TYPE fsType); BOOL IsFSTypeValid(FS_TYPE fsType); PQIDSTRGetMessageId ( ); // Partition Class Information BOOL CanCreatePrimary (); BOOL CanCreateLogical ( ); void SetPartitionClass(PART_CLASSnewtype); PART_CLASS GetPartitionClass ( ); PART_TYPEDeterminePartitionType ( ); BOOL IsHidden ( ); // Drive LetterInformation void GetAvailDriveLetters (char *LetterArray); voidSetDriveLetter(int LetterIndex); int GetDriveLetterIndex ( ); charGetDriveLetter ( ); // Set/get number of sectors before and after thisPartition ULONG GetSectorsAfter ( ); ULONG GetSectorsBefore ( ); voidSetSectorsAfter(ULONG ulNumSects, BOOL bResize); voidSetSectorsBefore(ULONG ulNumSects, BOOL bResize); // Volume LabelInformation virtual PQRET SetVolLabel(void *label, UINT uiBufLen = 0,UINT labelType = CP_DOS); void *GetVolLabel ( ); UINT GetVolLabelLength( ); UINT GetVolLabelType ( ); BOOL IsLabelChanged ( ); ULONGGetResizeIncrement ( ); VPartition *GetPartition ( ); protected: //Parent Partition & File System VPartition *Partition; VFileSystem*FileSystem; // Current Size and Position ULONG ulNewStartSect; ULONGulNewSize; // Min/max values for StartSect, EndSect, and Size ULONGulOldMinStartSect; ULONG ulMinStartSect; ULONG ulMinEndSect; ULONGulMinSize; ULONG ulMaxStartSect; ULONG ulMaxEndSect; ULONG ulMaxSize;FS_TYPE FSType; // Current File System Type ULONG ulResizeIncrement;void *VolumeLabel; UINT uiLabelLength; UINT uiLabelType; BOOLbLabelChanged; virtual void SetMessage ( ); // Dialog Warning Message IDPQIDSTR MessageId; int DriveLetterIndex; // Partition Class PART_CLASSPartclass; PART_CLASS OldPartClass; };

One or more corresponding file-system-specific limit classes can be usedto define additional limits which depend on the file system involved.For clarity of illustration, FIG. 4 shows a single instance of such aclass, in the form of a virtual FAT limits object 414. As with the othercomponents of FIG. 4, however, it will be appreciated that thefile-system-specific limits component(s) 414 need not be implementedusing C++ classes, much less by using the particular classes providedherein as examples. Other programming languages and paradigms may beused, including C, Pascal, or assembly, for instance, and less modularapproaches can be used than the C++ paradigm of classes and objects.

Moreover, as with the other file-system-specific component 410 shown inFIG. 4, file systems other than FAT file systems can be used in additionto, or in place of, a particular FAT file system in a given embodiment.Suitable file systems are identified herein and also known to those ofskill in the art.

Bearing this in mind, file-system-specific virtual limit objects 414 maybe implemented using a C++ class such as the following, which is acondensed revision of the class described in the '213 application:

class VFatLimits: public VLimits { public: VFatLimits (VPartition*Partition); BOOL IsFat16Available ( ); BOOL IsFat32Available ( ); PQRETInit (ULONG *ulFat16MinTbl, ULONG *ulFat16MaxTbl, ULONG *ulFat32MinTbl,ULONG *ulFat32MaxTbl, ULONG *ulClustsReqTbl, UINT64 *ulWaste, UINT64*ulUsed, ULONG ulCurSizeL, ULONG ulSPC, ULONG uIBPS, ULONG ulUsedRoot,ULONG ulRootCapacity, ULONG uIDataStartL, ULONG ulReservedL); virtualvoid SetStartSector(ULONG ulSect, BOOL bResize); virtual voidSetEndSector(ULONG ulSect, BOOL bResize); virtual void SetSize(ULONGulSize); void SetClustSize (ULONG ulClustSize); voidSetRootCapacity(ULONG ulNewCapacity); virtual PQRET SetFSType(FS_TYPEfsType); void GetClustInfo(ULONG ulClustSize, ULONG *ulUsedSects, ULONG*ulWastedSects, ULONG *ulMinSects, ULONG *ulMaxSects); ULONGGetClustSize ( ); ULONG GetMaxRootEntries ( ); ULONG GetMinRootEntries (); ULONG GetOldClustSize ( ); ULONG GetRecClustSize ( ); ULONGGetRootCapacity ( ); ULONG GetRootIncrement ( ); ULONGGetUsedRootEntries ( ); ULONG GetValidClustSizes ( ); FAT_TYPEGetFatType ( ); ULONG GetFirstDataSect ( ); virtual ULONGCalcMaxSize(ULONG ulMinStartSect, ULONG ulMaxEndSect); virtual ULONGCalcMinSize ( ); UINT64 *GetWasteTable ( ); UINT64 *GetUsedTable ( );int iGetClustIndex (ULONG ulNewClustSize); protected: void iSetClustSize(ULONG ulNewClustSize); void iSetSize(ULONG ulNewSize); voidiSetFatType(FAT_TYPE newType)  { type = newType; } void CalcActualRoot(void);   void ValidateClusterSize ( ); ULONG ulFat16Min[FAT_MAX_CLUST_SIZES]; ULONG ulFat16Max [FAT_MAX_CLUST_SIZES]; ULONGulFat32Min [FAT_MAX_CLUST_SIZES]; ULONG ulFat32Max[FAT_MAX_CLUST_SIZES]; ULONG ulClustsReq [FAT_MAX_CLUST_SIZES]; UINT64ulwaste [FAT_MAX_(‘3)CLUST_SIZES]; UINT64 ulUsed [FAT_MAX_CLUST_SIZES];// the “try for” values are used to try to give the user // what's askedfor, not just blindly pick a value that // works. For example, if acluster size is selected that // requires the partition to be resized,selecting the old // cluster size will return the size to its previousvalue. ULONG ulTryForSize; ULONG ulOldClustSize; ULONG ulClustSize;ULONG ulTryForClust; ULONG ulOldRootCapacity; ULONG ulRootCapacity;ULONG ulTryForRoot; FAT_TYPE oldType; FAT_TYPE type; FAT_TYPEtypeTryFor; // other important information ULONG ulUsedRoot; ULONGulBPS; // bytes per sector ULONG ulDataStart; ULONG ulReservedSectors;// work variables ULONG ulCurIndex;   // index # of the current clustersize };

One alternative to defining a virtual partition “class” to implementvirtual partitions 404 is to instance three separate classes, one eachfor primary, logical, and extended partitions 404. However, this makesit necessary to replace partition 404 updates that would otherwisesimply overwrite variables in an object with destroy-create sequencesthat free an object and create and initialize a replacement object,thereby slowing down execution of virtual partition 404 manipulations.

One alternative to using file-system-specific objects 410 is toencapsulate all necessary file system rules in a single global entity inthe virtual engine environment 206. A potential drawback of usingfile-system-specific limit objects 414 is that rules governing filesystems and partitions are spread throughout the program. As the user100 brings up a dialog to create a new partition, an implementationusing file-system-specific limit objects 414 must create a genericlimits object 412 which must calculate values for all file systems. Asthe user 100 selects the file system type to be created, theimplementation must recalculate and adjust for the specific partition404 involved. Redundant calculations must also be made in the filesystem object 408. The alternative creates a global Rules class thatcontains a list of rules objects governing the parameters for each filesystem type. This class is used for all calculations and thereforeensures consistent calculations throughout the virtual engineenvironment 206 and the real engine 210. For example, the Rules listcontains a FatRules object that is used to calculate minimum and maximumsizes, limits of expansion/contraction, limits to movement, and so forthfor FAT partitions 108.

Within one embodiment of the virtual engine environment 206, file systemtype conversion involves destroying the virtual file system object 410and replacing it with an instance of another virtual file system objectfor the target file system.

Batch Manager

When the user 100 is satisfied with the virtual changes shown in thevirtual engine environment 206, then the batch manager 208 may be usedto manipulate the live partitions 108 in a corresponding manner. Thebatch manager 208 keeps a persistent list of the commands beingperformed by the virtual engine 400. The batch manager 208 list ofcommands, when run by the real engine 210, will perform actual partition108 manipulation. This list may be implemented using C++ classes such asthe PQBatch* classes from the '213 application, incorporated herein. Inparticular, command or operation list generation may be implementedusing a C++ class such as the following, which is a condensed revisionof the class described in the '213 application:

class PQBatchMgrBuild { public: PQBatchMgrBuild ( ); virtual˜PQBatchMgrBuild ( ); PQRET Init( ULONG Flags, char *CmdLine, int argc,char *argv[ ], UINT CodePageType, ULONG *ulInProg, int Debug); PQRETUnInit ( ); BOOL AddDriveMapperOpToList (PQBatchDriveMapper *dmp, BOOLbAddToFront=FALSE); BOOL AddBatchOperation(PQBatchOperation *op); PQRETWriteBatchList (char *filename); void GetUniquePartitionID (VPartition*vPart, UNIQUE_PARTITION_ID *upid); BOOL TestIfPartitionIsLockable(VPartition *vPart); // Batch methods - these perform the actual batchtasks void InitOp ( VPartition *vPart, UNIQUE_PARTITION_ID *upid); voidInitOpConvert( VPartition *vPart, UNIQUE_PARTITION_ID *upid, FS_TYPENewFSType); BOOL DoCreate( VPartition *vPart, UNIQUE_PARTITION_IDunique_ID); BOOL DoDelete ( VPartition *vPart, UNIQUE_PARTITION_IDunique_ID); BOOL DoAdjust ( VPartition *vPart, UNIQUE_PARTITION_IDunique_ID); BOOL DoFATAdjust( VPartition *vPart, UNIQUE_PARTITION_IDunique_ID, ULONG ulclusterSize,FAT_TYPE newType,ULONG ulrootCapacity);BOOL DoFormat ( VPartition *vPart, UNIQUE_PARTITION_ID unique_ID); BOOLDoSetVolLabel ( VPartition *vPart, UNIQUE_PARTITION_ID unique_ID); BOOLDoHide ( VPartition *vPart, UNIQUE_PARTITION_ID unique_ID); BOOLDoUnHide ( VPartition *vPart, UNIQUE_PARTITION_ID unique_ID); BOOLDoSetActive ( VPartition *vPart, UNIQUE_PARTITION_ID unique_ID); BOOLDoBadSectorRetest( VPartition *vPart, UNIQUE_PARTITION_ID unique_ID);BOOL DoCopy( VPartition *vPart, UNIQUE_PARTITION_ID unique_ID, shortdestDriveId, ULONG destStartSect, ULONG destEndSect); BOOL DoConvertTo(VPartition *vPart, UNIQUE_PARTITION_ID unique_ID, FS_TYPE newFsType);BOOL DoDriveMapper(char oldDriveLetter, char newDriveLetter }; BOOLIsAnythingBatched ( ); BOOL IsEmpty ( ); void PurgeLists (void); BOOLGetDiskConfigSignature ( ); BOOL AddDiskConfigToList(DiskConfigCheck*dc); // Batch command optimization methods PQRET OptimizeList ( ); BOOLIsRebootNeededToExecute ( ); protected: PQBatchOperation *FirstOp;PQBatchOperation *LastOp; DiskConfigCheck *FirstDC; DiskConfigCheck*LastDC; PQBatchDriveMapper *FirstDM; PQBatchDriveMapper *LastDM; BOOLRebootNeededToExecute; };

After being stored, these commands can also be retrieved and edited. Forinstance, one embodiment of the batch manager 208 can optimize thestored lists. This may be accomplished by eliminating redundant moves,creations, deletions, and so on. It may also be accomplished by removingunnecessary file system checks between commands.

The batch manager 208 allows actual execution of the stored list. Beforebeginning execution, the batch manager 208 ensures that the real disk106 is in the same state as when the virtual engine 400 began storingthe list. If the states differ, the execution ends and the error isreported; otherwise, user data could be damaged or lost. This may beimplemented using a C++ class such as the DiskConfigCheck class and theBEFORE/NEW variables from the '213 application, incorporated herein.Actual execution of the listed operations may be implemented using thereal engine 210 and a C++ class such as the following, which is acondensed revision of the class described in the '213 application:

class PQBatchMgrExec { public: PQBatchMgrExec ( ) ; virtual˜PQBatchMgrExec ( ) ; PQRET PQBatchMgrExec::ReadBatchList (char*filename) ; PQRET CreateBatchObjectFromString (char *line) ; char *ScanForUniqueID(UNIQUE_PARTITION_ID *pUniqueID, char *linePtr) ; char *ScanForULong ( char *srchStr, char *startPtr, char *linePtr, ULONG*ulVal) ; char * ScanForUShort ( char *srchStr, char *startPtr, char*linePtr, USHORT *usVal) ; char * ScanForUChar ( char *srchStr, char*startPtr, char *linePtr, UCHAR *ucVal) ; char * ScanForString( char*srchStr, char *startPtr, char *linePtr, ULONG maxlen, char *string) ;char * ScanForDelim(char *string, char *delim) ; PQRET ParsePMHeader(char *linePtr) ; PQRET ParseDriveMapperCommand (char *linePtr) ; PQRETParseDiskConfigData (char *linePtr) ; PQRET ParseCreateCommand (char*linePtr) ; PQRET ParseDeleteCommand (char *linePtr) ; PQRETParseAdjustCommand (char *linePtr) ; PQRET ParseFATAdjustCommand (char*linePtr) ; PQRET ParseSetVolLabelCommand (char *linePtr) ; PQRETParseHideCommand (char *linePtr) ; PQRET ParseUnHideCommand (char*linePtr) ; PQRET ParseSetActiveCommand (char *linePtr) ; PQRETParseCopyCommand (char *linePtr) ; PQRET ParseFormatCommand (char*linePtr) ; PQRET ParseConvertToCommand (char *linePtr) ; PQRETParseBadSectRetestCommand (char *linePtr) ; BOOL AddBatchOperation(PQBatchOperation *op) ; BOOL AddDriveMapperOpToList (PQBatchDriveMapper*dm) ; PQRET ExecuteList ( ) ; short GetOperationCount ( ) ; shortGetDriveMapperOpCount ( ) ; BOOL IsAnythingBatched ( ) ; BOOL IsEmpty () ; BOOL AddDCToList (DiskConfigCheck *diskConfig) ; PQRETCheckDiskConfig ( ) ; protected: PQBatchOperation *FirstOp;PQBatchOperation *LastOp; DiskConfigCheck *FirstDC; DiskConfigCheck*LastDC; PQBatchDriveMapper *FirstDM; PQBatchDriveMapper *LastDM; };

The batch manager 208 can also determine whether a partition 108 maysafely be manipulated during the present user session; somemanipulations should instead be performed later in boot mode. The batchmanager 208 can determine whether a reboot into an alternate executionmode controlled by the inventive software will be necessary before liveexecution of operations (to obtain a lock on a partition 108 which isnot otherwise readily locked), and whether a reboot will be needed afterlive execution of operations on partition(s) 108 to update structures inoperating system memory with changes newly committed to disk 106. Thealternate execution mode interrupts the boot process and thus permitsthe inventive software to do its work before the operating systemfinishes loading. On a Microsoft Windows NT system, for instance, theinventive software may include an application that looks to the WindowsNT operating system like a protected subsystem of that operating system,but is actually an application program running at so-called “subsystemload time”.

Generally, a reboot into the alternate execution mode is needed if theinvention's embodiment cannot obtain a lock on a partition 108 from theoperating system. That is, boot mode provides an exclusive lock on thedrive before performing operations, and allows execution of batchedoperations before the operating system takes control. If new driveletters are created by partition manipulations, some operating systems(such as Windows 95 and other Windows environments) require a reboot toupdate the operating system's view of the drive letters now being usedon the disk(s) 106.

The drive mapping utility automates the update of drive references in*.ini files and registry files when drive letter changes are made bypartition manipulation. In one embodiment the batch manager 208 alsogenerates drive mapping commands. Since the sequence in which drivemappings are changed is critical, the batch manager 208 manages drivemapping sequencing for a drive mapping utility. Suitable drive mapperscan be implemented using a C++ class such as the PQBatchDriveMapperclass from the '213 application, incorporated herein, with drive mappingfunctionality familiar in the art, such as that found in the PowerQuestPartitionMagic version 3.0 DriveMapper utility.

Wizards

One embodiment of this invention provides one or more wizards 212 tohelp users 100 perform common actions. For example, a user 100 could aska wizard 212 to virtually optimize free space on a given drive. Thewizard would then decide without further user input how to perform theoptimization. In one embodiment the wizard 212 does not provide anyextra functionality, in the sense that everything the wizard 212 doescan be done by the user 100 using the virtual engine environment 206directly through the user interface 200 without the wizard 212.

However, wizards 212 provide convenient shortcuts for expert users 100and helpful guidance to novice users 100. The functions listed below canbe automated using one or more wizards 212 in conjunction with thevirtual engine environment 206. As mentioned above, all the functionshere are performed “virtually” but also generate a list of commands todrive real manipulations performed by the real engine 210 if so desired:

Optimize free space on a drive and within partitions by reducing clustersizes and converting to more efficient file systems.

Optimize move and resize operations to perform the minimal amount ofdata moving necessary.

Show the before and after state of the disk before the user 100 commitsthe changes proposed by the wizard.

Determine the optimal size based on the selected operating system.

Allow the user 100 to adjust the optimal size.

Automatically add partitions to the boot manager, create the partition,and move other partitions to make room for a new partition.

Automatically reduce cluster size or convert to a new file system toreclaim wasted space.

Analyze the user's disk configuration and recommend ways to use the diskmore effectively.

Allow the user 100 to set constraints on whether a given partition canbe moved or resized. If the partition can be resized, determine theminimum size for the partition. This is used for placing constraints onthe algorithm that determines changes to the partitions when creating anew partition, rebalancing freespace, or reclaiming wasted space, andwhen preparing to install a new operating system.

Adjust logical partitions and primary partitions to make room for a newoperating system partition.

Shrink existing partitions just enough to make room for new partitionscreated with the wizard.

Create a primary or a logical partition, based on the context of thewizard operation.

Methods

FIG. 5 illustrates methods of the present invention. During an obtainingstep 500, an embodiment of the invention obtains one or more virtualpartition 404 manipulation commands from the user 100. The embodimentmay include inventive software like that shown in FIG. 2 and/or aninventive system like one or more computers shown in FIG. 3, configuredwith code and/or hardware to operate according to the methods describedherein.

The obtaining step 500 may be accomplished in one or more of a group ofways. For instance, the embodiment may obtain the command interactivelyfrom the user 100 through a command line interface 200 or a graphicaluser interface 200. Or the command may be obtained from a batch file orscript that is created by the user 100 and then read by the userinterface 200.

Likewise, the command may be obtained locally, in the sense that theuser 100 directly operates the same machine that is running the userinterface 200 and the virtual engine environment 206, or the command mayobtained from a remote user 100 over a communications link 306.

In the case of remote users 100, various approaches are possible. In themost separated case, the user 100 generates commands at one computer,sends them to a second computer for simulation, and performsmanipulations on a storage medium 106 attached to a third computer, butvariations involving fewer computers and locations are also possible.

In one approach, the computer to which the storage device 106 isattached is deemed local, and a simulating step 502 locally simulates atleast one operation which may be performed 516 locally in response tothe remote user's command. For instance, in response to a user's commandfrom location R, a computer at location X runs the virtual engine tosimulate manipulation of a disk 106 that is attached to the computer atlocation X.

In a second remote user 100 approach, the computer to which the storagedevice 106 is attached is again local, but the simulating step 502remotely simulates at least one operation which may be performed 516locally in response to the remote user's command. For instance, inresponse to a user's command from location R, a computer at location Rsimulates manipulation of a disk 106 that is attached to a computer atlocation X.

In a third remote user 100 approach, the computer to which the storagedevice 106 is attached is also remote, and the simulating step 502locally simulates at least one operation which may be performed 516remotely in response to the remote user's command. For instance, inresponse to a user's command from location R, a computer at location Ysimulates manipulation of a disk 106 that is attached to the computer atlocation R.

In a fourth remote user 100 approach, the computer to which the storagedevice 106 is attached is remote, and the simulating step 502 remotelysimulates at least one operation which may be performed 516 remotely inresponse to the remote user's command. For instance, in response to auser's command from location R, a computer at location X simulatesmanipulation of a disk 106 that is attached to a computer at location Y.

During the simulating step 502, the embodiment simulates partitionmanipulation in the virtual engine environment 206. This can beaccomplished using computers, networks, computer program storage media,and/or other devices and machines configured according to the methods,structures, and/or codes described herein, in a wide variety ofdifferent combinations.

It will be appreciated from the information provided throughout thisdocument that the simulating step may include simulated partition 404creation (creating a simulated logical partition 404, a simulatedprimary partition 404, and/or a simulated extended partition 404);simulated partition 404 formatting; simulated partition 404 replication;simulated partition 404 deletion; simulated partition 404 resizing bychanging the number of sectors in the simulated partition 404; simulatedpartition 404 resizing by changing the cluster size of the simulatedpartition 404; simulated partition 404 resizing by changing the size ofa simulated extended partition 404 in connection with resizing asimulated logical partition 404 within that simulated extended partition404 so that the extended partition 404 continues to properly contain thelogical partition 404; simulated partition 404 resizing by expanding asimulated extended partition 404 into free space that is obtained bymanipulating another simulated partition 404 outside the simulatedextended partition 404; changing the root directory size of a simulatedpartition 404; renaming a simulated partition 404; simulated partition404 conversion by changing the file system type of the simulatedpartition 404, such as conversion between FAT16 and FAT32 file systemformats, and possibly thereafter displaying 504 an indication of thesimulated partition's free space and/or used space after the conversion;changing the hidden status of a simulated partition 404; and/or changingthe active status of a simulated partition 404.

The simulating step 502 optionally inserts a placeholder for a step 514of verifying the integrity and consistency of live internal file systemdata in connection with performing 516 manipulations that werepreviously simulated 502. Such consistency checks 514 are generallyworthwhile, but some real engines 210 will perform them regardless ofwhether they are expressly instructed to do so by a simulation-providedplaceholder.

The simulating step 502 optionally inserts a placeholder for a step oftesting for bad sectors in a live partition 108. Bad sector testing canbe time-consuming but is worthwhile with some media 106 and/or in caseswhere a partition 108 manipulation would place data on a previouslyunused portion of the media 106. The discussions of bad sector testsgiven in the '769 and '472 patents are incorporated herein.

During a providing step 504, the embodiment provides the user 100 withthe results of the simulation(s) done during step 502. This may beaccomplished by displaying modified partition information on a text orgraphical user interface 200, in the case of human users 100. Resultsmay also be provided 504 by data transfer from the embodiment to acomputerized or automated user 100. Special display objects may be usedto facilitate this step 504; these display objects include copies of asubset of the virtual engine environment 206 objects. In one embodiment,the display objects include one or more instances of a C++ class such asthe following, which is a condensed revision of the class described inthe '213 application:

class VPartitionDisplayInfo { public: VPartitionDisplayInfo (VPartition*Partition) ; VPartitionDisplayInfo ( ) ; ULONG GetUsedSectors ( ) ;ULONG GetStartSector ( ) ; ULONG GetSectorCount ( ) ; FS_TYPE GetFSType( ) ; BOOL IsLogical ( ) ; VFileSystem *GetFileSystem ( ) ; BOOLGetIsHidden ( ) ; VPartitionDisplayInfo* GetNext ( ) ;VPartitionDisplayInfo* GetPrev ( ) ; void SetFileSystem ( VFileSystem*FileSys ) ; void SetStartSector ( ULONG StartSector ) ; voidSetSectorCount ( ULONG SectorCount ) ; void SetUsedSectors ( ULONGUsedSectors ) ; void SetFSType ( FS_TYPE FSType ) ; void SetIsLogical (BOOL IsLogical ) ; void SetIsHidden ( BOOL IsHidden ) ; void SetPrev (VPartitionDisplayInfo *Object ) ; void SetNext ( VPartitionDisplayInfo*Object ) ; void Remove ( ) ; void InsertAfter ( VPartitionDisplayInfo*NewObject ) ; VPartitionDisplayInfo *pNext; VPartitionDisplayInfo*pPrev; VFileSystem *FileSystem; ULONG ulStartSector; ULONGulSectorCount; ULONG ulUsedSectors; PART_CLASS usPartitionClass; FS_TYPEfsType; ULONG VolType; BOOL bIsLogical; BOOL bIsHidden; charPartitionTypeName[64]; ULONG ReSizeSector; };

During an optional editing step 506, the embodiment allows users 100 toedit a list of desired partition 404 operations. For instance, the user100 may undo at least one operation previously specified by the user100, or change manipulation parameters (e.g., cluster size, partitionsize) previously specified in the list. The editing step 506 may includeexpress interactive editing by the user 100 and/or implicit editingthrough optimization of the command or operation sequence. In otherembodiments, editing 506 only includes express list editing by the user100 and optimization is viewed as a separate step 512 or is not present.More generally, embodiments may group the various method steps describedhere in different ways and/or label them differently. What matters iswhether the functionality described here is present, at the level ofspecific steps being taken at some point.

During an optional storing step 508, the embodiment stores the list ofdesired partition operations in persistent storage as user data; thelist is retrieved during a step 510. The persistent storage may be onthe medium 106, on a program storage medium, or on another medium. Filestorage and retrieval generally are well known, although their use inthe context of virtual engine environments 206 is new. Syntaxes forspecifying partition manipulation commands or operations to a realengine 210 are also well known, and can be used to help create commandsduring storage 508 and to parse commands during retrieval 510. Thevirtual commands differ from conventional real engine 210 commands inthat the virtual commands identify virtual drives 402 and virtualpartitions 404, rather than live drives 106 and live partitions 108. Forinstance, a virtual command may contain a pointer such as the VPartition*Partition pointer.

During an optional optimizing step 512, the embodiment optimizes thelist of desired partition manipulation commands or operations.Optimization may be done to reduce the time needed to perform the listduring step 516, to optimize storage device 106 use (maximize freespace, minimize expected access time during later use of the partitions108, or pursue other familiar goals), or to promote some combination ofthe two types of optimization.

Possible optimizations include removing a first set of one or morepartition operations that is made redundant by a second, later set ofone or more partition operations (e.g., manipulations of a partitionthat is to be subsequently deleted); reducing the amount of datamovement required by a set of partition operations (e.g., replacing amove from A to B followed by a copy back to A with a copy from A to B);redistributing free space on a storage device; increasing free space ona storage device by reducing cluster size; increasing free space on astorage device by converting file system type; and/or specifying(identifying or creating) free space and then creating an operatingsystem partition for installing an operating system, possibly followedby adding the operating system partition to a boot manager structure.

During a consistency checking step 514, the embodiment checks forinconsistencies that could lead to lost or corrupted user data if notdetected and fixed. For instance, before performing 516 manipulations onlive partitions 108 which correspond to simulated 502 manipulations, theinventive system verifies that the current actual disk configuration 106matches the configuration in the virtual environment 206 as of thebeginning of the simulation. If it does not, the user 100 is notifiedand no live manipulation based on the simulation will be performed.

The step 514 may also check the virtual environment 206, the live data104, 108, or both, for file system consistency and integrity and/orpartition definition integrity. The discussions of integrity andconsistency checks and verification given in the '769 and '472 patentsare incorporated herein.

To enforce internal consistency and compliance with the assumptions madeby operating systems, one implementation of the invention does thefollowing in connection with step 514. First, a unique state ID isassociated with a starting state of a given partition 108, for eachpartition 108 represented in the virtual environment 206. This state IDis used to link the list of operations to the live partition 108 in thatpartition's starting state; executing the list on another partition 108or on the same partition 108 from a different starting state coulddestroy user data.

Second, the list of operations sent to the real engine 210 for execution(if the user authorizes committing the command(s) to disk during step516) includes information used by the real engine 210 to verify that thestate of the live partition 108 matches the state presumed by thevirtual partition 404 in requesting the operation. This can be done bycomparing the value of boundaries and other limits to be changed whichare provided by the virtual engine environment 206, on the one hand, toeither the real engine's data structures (e.g., a partition informationlist such as that in PowerQuest PM 3.0) or the actual values on disk 106(e.g., in the partition table 104). Again, the goal is to verify thatthe live disk 106 organization matches the organization presumed by thevirtual engine 400.

Third, the virtual engine 400 relies on limits embedded in the virtuallimits objects 412, 414 and on constraints (no nested extendedpartitions, no overlapping primary partitions, no partitions beyond adisk boundary, etc.) embedded in the virtual engine 400 functions.Compliance with these constraints can be verified during a separatestep, or verification can be integrated with a step of documenting freespace or the step 510 of retrieving the operations list.

In one implementation, the virtual engine environment 206 includescopies of the system structures such as the file allocation table, and amodified CHKDSK program verifies the integrity and internal consistencyof these structures. In another implementation, the file systemstructures are mainly not copied in the virtual environment 206; only anindication of file system structure characteristics such as fileallocation table size and the size of other space allocated by the filesystem within a partition is maintained in the virtual environment 206.In one embodiment a table of the following information is keptinternally by the implementing software, depending on the FAT filesystem type and/or the specific partition ID: cluster size, minimumpartition size, maximum partition size, used and free sectors within thespecific partition, used and wasted space within the specific partition.

During a performing step 516, the embodiment performs on the live medium106 manipulations corresponding to the simulated manipulations (subjectto changes in the list made by optimization and by translation fromvirtual identifiers to live structure identifiers). This is accomplishedwith the real engine 210, which receives and executes one or moreoperations provided by the batch manager 208, which in turn creates thelive manipulation operations based on the list of simulated commandsprovided to the virtual engine 400.

FIG. 5 is meant to assist an understanding of the present invention, notto summarize every aspect of the invention or even every method. Themethods, signals, systems, and configured storage media of the inventionare defined by the claims, in view of the entire specification, notmerely by FIG. 5. Steps may be repeated; for instance, steps 500 to 504may be repeated several times before step 514 occurs. Steps may also beomitted. For instance, any of editing, storing, retrieving, andoptimizing steps 506-512 may be omitted (although a storing step 508 isneeded before a retrieving step 510). Likewise, one may exit theflowchart of FIG. 5 after the simulation results are provided duringstep 504, without performing 516 any live manipulations. Steps may alsobe reordered or done concurrently, unless one step requires the resultof a previous step. For instance, one might optimize 512 a list eitherbefore or after storing 508 it. Moreover, steps may be groupeddifferently or renamed. These variations may be present in an embodimentregardless of whether they are expressly described or shown as optionaloutside the claims.

Signals

FIG. 6 illustrates a virtual partition signal 600 according to theinvention. The signal 600 may be embodied in a computer 304 and/or 308memory, in the storage medium 106, in a separate configured programstorage medium, and/or in the wire 306. Other signals according to theinvention are defined by the source code excerpts and other descriptionsherein, and may likewise be embodied in various physical devices and/ormedia.

The virtual partition signal 600 may be implemented as part of aVPartition C++ class or similar as shown above or in '213 application.The illustrated signal 600 includes a virtual drive identifier 602 whichidentifies a virtual drive 402. Unlike a physical drive 106 identifier,the virtual drive identifier 602 may be implemented in the virtualengine environment 206 as a memory pointer (address) or as an index intoan array, such as a pointer or index into a list or array of VDriveobjects.

The illustrated signal 600 also includes a file system identifier 604which identifies a file system type. In one embodiment, the identifier604 either identifies an existing file system such as a FAT file systemor it indicates that no file system is yet associated with the virtualpartition 404 in question.

The illustrated signal 600 also includes a partition class identifier606 which identifies a class (primary, logical, or extended) for thevirtual partition 404 in question.

Finally, the illustrated signal 600 includes a virtual partitionidentifier 608 which identifies a virtual partition 404. Unlike a livepartition 108 identifier, the virtual partition identifier may beimplemented in the virtual engine environment 206 as a memory pointer(address) or as an index into an array, such as a pointer or index intoa list or array of VPartition objects.

FIG. 6 is meant to assist an understanding of the present invention, notto summarize every signal of the invention or even every virtualpartition signal. The methods, signals, systems, and configured storagemedia of the invention are defined by the claims, in view of the entirespecification, not merely by FIG. 6. Signal components may be repeated;for instance, several virtual partition identifiers 608 may beassociated with a given virtual drive identifier 602. Signal componentsmay also be omitted. For instance, if no file system is yet associatedwith the virtual partition 404 in question, that may be indicated by thelack of a file system identifier 604. Signal components may be stored indifferent orders or arrangements than that shown, and may be associatedby being stored together and/or by links such as a pointer or tableindex. Moreover, signal components may be grouped differently orrenamed. These variations may be present in an embodiment regardless ofwhether they are expressly described or shown as optional outside theclaims.

Additional Implementation Notes

Primary partitions 108 are those appearing in the Master Boot Record(“MBR”) partition table 104. Present versions of the partition table 104limit the number of primary partitions 108 known to an operating systemto four, of which only one may be an extended partition 108, but thismay be changed in the future and corresponding changes toimplementations of the invention will be readily made by those of skillin the art. An extended partition 108 is a primary partition 108 butserves as a shell to hold one or more logical partitions 108. A logicalpartition 108 must be inside an extended partition 108. An extendedpartition 108 must be contiguous (it cannot be defined to cover two ormore separate sector ranges), and extended partitions 108 may not benested. Again, these restrictions may change in future operatingsystems, and corresponding changes may then be made in implementationsof the invention.

The first primary partition 108 on the disk 106 (at least under Windowsbrand and DOS operating systems) is always notched. A “notched”partition is a partition that does not begin in the first sector of acylinder boundary. Instead, a notched partition normally begins on thesecond head past the cylinder boundary, that is, one head from thebeginning of a cylinder. Logical partitions 108 are always notched.Second, third or fourth primary partitions 108 are not necessarilynotched. Care must be taken when manipulating a flat (non-notched)primary 108 to create a logical partition 108, because partitionresizing and/or data relocation may be needed to make room for the notchwithout losing user data. Links between extended partition boot recordsmust also be updated when a logical partition 108 is inserted ordeleted.

Active partitions 108 are bootable. Hidden partitions 108 are notassigned a drive letter under various DOS or Windows brand operatingsystems. Some users 100 would like to have more than four differentbootable partitions 108, with the different partitions 108 runningdifferent operating systems and/or different versions of an operatingsystem and/or different copies of the same version of a given operatingsystem.

One novel way to do this, either with a virtual environment 206 and areal engine 210 as a pair or merely with a real engine 210, is tocoordinate partition 108 manipulation with boot management as follows.The user 100 selects a partition 108 to boot. If the partition 108 isalready a primary partition 108, the boot manager boots from thatpartition 108 in a manner familiar to those of skill in the art. If thepartition 108 is a logical partition 108 and one of the four partitiontable 104 entries is open, then the logical partition 108 is changed toa primary partition 108 and entered in the partition table 104, theextended partition 108 holding the former logical partition 108 isresized to exclude it, and the boot manager boots from the new primarypartition 108. If no partition table 104 entry is available, then one ofthe non-extended primary partitions 108 is moved into the extendedpartition 108, thereby becoming a logical partition 108 and freeing apartition table 104 entry for use by the partition 108 which is to bebooted.

In changing partitions 108 from logical to primary or vice versa, it maybe necessary to move or combine partitions 108 so that only one extendedand only four or fewer primary partitions 108 are present. For instance,consider a disk 106 containing partitions P1, P2, P3, and E, in thatorder, where Pn is a non-extended primary partition 108, E is anextended partition 108, and E contains logical partitions 108 L1, L2,L3, and L4 in that order. To boot from L3, the implementing softwarecould make L3 and L4 primaries 108, make P2 and P3 logical partitions108 in an extended 108 that also contains L1 and L2, and leave P1 as is.The four partition table 104 entries would then identify (i) P1, (ii) anextended partition 108 (containing P2, P3, L1, and L2), (iii) L3, and(iv) L4. L3 would become a primary 108 to be subsequently booted by theboot manager in a familiar manner.

But a similar approach will not work to boot L1 because there are notenough partition table 104 entries. As a bootable primary 108, L1 willneed one partition table 104 entry. There are three partitions 108before L1 and three after it, and only one of the two groups of threepartitions 108 can be subsumed into an extended partition 108 thatrequires only one partition table 104 entry. Thus, five partition table104 entries would be needed. One solution is to move L1 and then use theapproach previously described, with L1 outside the extended partition108 and enough of the other partitions 108 placed inside the extendedpartition 108 to bring the number of primary partitions 108 down tofour. However, moving a partition 108 may be time-consuming.

Another solution is to create an enhanced partition table 104 used onlyby the boot manager. Using the enhanced partition table 104, the bootmanager tracks the seven partitions 108. Two or more of the partitions108 are combined into one partition 108 in the regular partition table104 used by the operating systems. This is safe only if the enhancedpartition table 104 is carefully preserved and always referenced duringboots; only the boot manager would be used to boot the machine.Otherwise, user 100 or system data may be damaged or lost in a partition108 that appears in the enhanced partition table 104 but not in theboot-manager-modified regular partition table 104.

One basic control loop for the system shown in FIG. 2 proceeds asfollows. First, the system initializes one or more virtual partitionobjects in the environment 206 by reading values (partition location,class, size, volume label, etc.) from the real engine 210. The realengine 210 should check the MBR for consistency and a correct signature.Next, the virtual engine 400 obtains a user command through the userinterface 200. Once the partition(s) 108 involved are identified, thelimits on partition manipulation are determined and embedded in virtuallimits object(s) 412 and/or 414. The virtual partition 404 beingoperated on is updated (this is preferred but it may also be destroyedand replaced by a new object with the post-manipulation values). Thevirtual file system object(s) 408 and 410 are destroyed and a newinstance with the specified file system is put in its place.

A given user 100 command may correspond to one or more operations.Typical users specify commands, while the batch manager 208 and thevirtual engine 400 generally use operations internally rather thancommands. An advanced user 100 may be allowed to manipulate a list ofcommands during step 506 and/or step 512. To illustrate the differencebetween commands and operations, and to illustrate other aspects of theinvention as well, the following examples are provided.

EXAMPLE ONE

Assume a current disk 700 organization similar to that shown at the topof FIG. 7, with a first partition A indicated at 702, an extendedpartition 704, free space 706, and a second partition 708 (or severalpartitions 108 where the second partition 708 is shown). Assume furtherthat the user 100 wishes to expand the first partition 702 into the freespace 706 located at the right of that partition 702. The correspondinguser 100 command may be in the form “expand partition A to the right by50%” or “grow A by 75 Megabytes” (with growth defaulting to growth tothe right), or the user 100 may enter the command through the graphicaluser interface 200 by dragging, to the right, the right edge of arectangle which represents partition A.

The virtual engine environment 206 and/or batch manager 208 maytranslate this single user command into several operations, asillustrated. The first operation resizes the free space 706 by movingits left edge; this is mainly an internal “bookkeeping” operation but itmay also be graphically shown to the user 100 to indicate progresstoward completion of the command. The second operation resizes theextended partition 704, because otherwise the partition 702 would bepartially within and partially outside the extended partition 704 andthis would violate the assumptions made by operating systems and placethe user's data at risk. The first and second operations may be combinedin some embodiments. That is, moving the boundary of an extendedpartition may automatically also move the corresponding boundary of freespace that adjoined the extended partition boundary. Finally, a thirdoperation resizes the partition 702 into the vacated region.

EXAMPLE TWO

Assume a current disk 800 organization similar to that shown at the topof FIG. 8, with a first partition A indicated at 802, an extendedpartition 804, free space 806, and used space 808 allocated to apartition B and zero or more additional partitions 108. Assume furtherthat the user 100 wishes to move the partition 802 to a location in theextended partition 804 at the left of the used space 808. Thecorresponding user 100 command may be in the form “move A to the left ofB” (with movement across one boundary of an extended partitiondefaulting to movement into the extended partition), or the user 100 mayenter the command through the graphical user interface 200 by draggingthe rectangle which represents A into the desired position next to therectangle that represents B.

The virtual engine environment 206 and/or batch manager 208 translatethis single user command into several operations, as illustrated. Thefirst operation removes the free space partition 404/806; since thepartition A is larger than the free space 806, merely resizing the freespace 806 will not suffice. The extended partition 804 is then resizedto enclose both A (still in its original location) and the partition(s)in the used space 808. If the user 100 command had been “make A into alogical partition” then operations could stop at this point.

To continue operations arising from the command “move A to the left ofB,” partition 802 is moved into the free space represented by thedeleted free space partition 404 object in the environment 206. Notethat the new location of partition A overlaps the original location, socare must be taken to move data in the correct order to avoid losinguser data; one approach starts at the right edge of A and relocates A'sdata in right-to-left order, so that the data in the overlapped regionhas been relocated by the time that region is overwritten with a copy ofdata from the left end of partition A. The extended partition 804 isthen resized again to fit snugly around partitions A and B; the defaultresult puts newly freed space that would otherwise be at one end of anextended partition outside the extended partition 804. Finally, a newfree space partition object 404/810 is created to represent the space nolonger occupied by A.

Alternative embodiments use different operations and/or data structuresto accomplish the desired result(s). For instance, assume the statesillustrated in FIG. 8 are numbered consecutively, with state 1 being theinitial state shown at the top of the Figure, state 2 the next state,and so on. One alternative approach would eliminate state 2, would showfree space structures 812 in states 3 and 4, and would eliminate state5.

It is believed that a commercially available product, marketed under thename “Partition-It” by Quarterdeck Corporation, may be able to grow anextended partition 108 to accommodate growth of a logical partition 108.However, at least as of the filing date of the '213 application, thatproduct was apparently unable to shrink an extended partition 108 tomake room for a new primary partition 108 outside and next to theextended partition 108.

In performing a partition 404 move, one implementation of the inventiondetermines the virtual limits captured in structures 412, 414information and displays those limits to the user through the userinterface 200. The move may then be specified in terms of free spacedesired to the left or right of an existing partition. The virtualpartition object 404 corresponding to the moved partition 108 is updatedaccordingly as part of the move.

EXAMPLE THREE

File systems may also be converted, such as conversion between FAT12 orFAT16 and FAT32 file systems, and conversion from FAT to NTFS or HPFSfile systems. Conversion in the context of a real engine 210 only (novirtual engine 400) is known in the art. For instance, Microsoftprovides a tool to convert FAT partitions into NTFS partitions, andPowerQuest supports conversion from FAT32 to FAT in its PartitionMagic®3.0 product (PARTITIONMAGIC is a registered trademark of PowerQuestCorporation).

Within the virtual engine environment 206, conversion involvesdestroying the virtual file system object 410 and replacing it with aninstance of a virtual file system object 410 for the target file system;more details are provided in the code given above and in the '213application. Like the other examples of virtual partition 404manipulation, conversion in the virtual engine environment 206 may alsoinvolve having the batch manager 208 build a list of one or moreoperations for possible later execution by the real engine 210 (possiblyafter optimization by the batch manager 208 or user 100).

EXAMPLE FOUR

A FAT partition 404 is to be copied into free space. After the copycommand completes, two copies of the partition 404 will exist in thevirtual engine environment 206, and after the copy operation iscommitted to the disk 106, two copies of the live partition 108 and itscontents will exist on the disk or other storage medium 106.

In the virtual environment 206, the FAT partition 108 has acorresponding virtual partition structure 404 and an associated virtualfile system structure 410. The free space is represented in the virtualenvironment 206 as a free space partition 404, and thus has a virtualpartition structure and associated virtual file system structure 410(specifying FAT by default) of its own. By contrast, unformattedpartitions 404 represent partitions 108 that exist on disk 106 and havean entry in the MBR or EPBR, and typically have the first sectorformatted to contain hexadecimal value 0×F6. Rather than deleting onepartition 404 structure and then creating a new one if thelogical/primary status is changing, the copy operations simply updatethe “class” indicator of the free space partition 404 to make it logicalor primary. The copy operations also destroy (e.g., remove from anyvirtual engine environment 206 list and deallocate memory used by) thefree space partition's virtual file system object 410, and instantiate anew instance of the virtual file system C++ class, and associate the newinstance with the updated virtual partition 404 structure.

At the end of the partition copy command, the implementation scans thevirtual environment 206 list of partitions 404, identifying free spaceand documenting it by creating new free space virtual partition 404 andvirtual file system object 408 pairs to represent the free spaceconfiguration after the partition is copied. Similar scanning and freespace documenting steps are also performed at the end of move, create,delete, and other partition 404 manipulation commands.

In one implementation, the scanning step divides the disk 402 or otherstorage medium into segments; a list of segments is stored in thevirtual environment 206 solely for internal use by the virtual engine400. Segment boundaries are defined at the edges of existing partitions404, at size limits imposed by operating systems (e.g., 1024 cylinderboundary), and at the physical edges of the disk 402. Each segment islabeled as primary, extended, or logical, and is also labeled as used orfree. Segments that must be “notched” to make room for an MBR are somarked. Finally, the free space partitions 404 are created fromcorresponding free segments. Maintaining the list of segments makes iteasier to create the free space partitions 404 and to manipulatepartitions 404 during operations such as those shown in FIG. 8, byproviding a separate (from the virtual partitions 404) state informationstructure that shows boundaries and partition “class.”

Partition Creation

Partition 404 creation is performed by taking an existing free spacepartition 404 structure and changing its type and position/size to thatof the parameters specified by the user 100. The associated file systemobject 410 is destroyed and a new one is created for the specified filesystem. This file system object 410 is created with default values forthe file system type and size. For example, if the user 100 specifiesthat a new FAT partition be created, the file system will be calculatedwith the FAT, root directory, and so on having the appropriate sizes forthe partition size. Sectors which are used by the file system arecalculated and represented to the user 100, as well as free sectors inthe partition 404, during step 504.

One method for doing this has a volume object that represented both thepartition and the file system, but this is problematic. When creating anew partition, a new volume object has to be created and destroyedrepeatedly in order to create a new partition, and then formatted to thecorrect type. The preferred split architecture discussed at lengthabove, which keeps the partition object and just deletes andinstantiates a new file system object, is easier and more efficient.

Partition Formatting

The split architecture, which separates the partition object 404 fromthe file system object 410, also makes formatting a virtual partition404 into a simpler operation. The system simply changes the partitiontype in the MBR entry, and deletes and instantiates a new file systemobject 410 for the specified file system. This new file system object410 is then configured to represent the specific file system attributesin the virtual engine environment 206.

Partition Replication

Partition replication is also made easier by the preferred splitarchitecture. The destination partition object 404 is changed to reflectthe size of the source partition 404 and the file system object 410 iscopied into the destination partition object 410. Situations where drivegeometry is different on the source than the destination should bedetected and handled. The corresponding partition 108 may need to beresized, but the real engine 210 handles this. All the virtual engine400 need do is validate the size of the destination partition 404 andreplicate the limits 412 of the original partition.

Partition Deletion

Partition deletion comprises deleting the partition object 404 andassociated file system object 410, and then deleting and regeneratingfree space objects in the system. Free space objects 404 should beregenerated because the newly created free space may be adjacent toanother free space object which should be merged to create one partitionobject 404 representing the combined free space.

Partition Resizing

This operation uses the same information obtained from the real engine210 as is discussed in the '982 application. In particular, thepartition minimum and maximum sizes, sectors used, bytes used and wastedare calculated for the partition 404 before the resize is performed.Bytes used and wasted are accounted for as additional information thatis only used when performing a cluster analysis and is not always readfrom the on-disk partition 108 unless it is absolutely necessary for thecurrent operation.

Extended Partition Manipulation With Partition Resizing

Operations on an extended partition 404 (creation if it doesn't alreadyexist, deletion if the adjacent primary partition covers an emptyextended partition, or resizing) are executed during manipulationperformance 516 before any subsequent operations on the logical orprimary partitions 108 involved. This puts the real engine 210 in avalid state to perform 516 the operation on the specified logical orprimary partition(s) 108. Care must be taken to delete an extendedpartition if a primary partition is resized to cover the extendedpartition.

File System Conversion

This operation takes information from the previous file system object410 and determines the file system parameters for the new file systemtype. For FAT to FAT32 conversions, a table of used, min, and maxsectors for each cluster size and file system type (FAT16 and FAT32) iskept and used in the conversion to determine the new file systemparameters. Conversions from FAT to NTFS require no substantial supportin the virtual engine environment 206, since the embodiment simply runsthe Microsoft Windows NT conversion program immediately and thenreinitializes the virtual engine environment 206. Conversions from FATto HPFS must go through file-system-specific calculations on the numberof files and the total used sectors to determine used and free sectorsafter the conversion.

Storing a List of Operations

Storage is provided during step 508 for a copy of a list of operationscreated by the virtual engine 400 to allow optimization 512 andverification 514. As each command is executed by the virtual engine 400,a structure is written which provides verification information about theexisting partition 108. After the virtual engine 400 has executed itsoperations, it communicates to the batch manager 208 to store theoperation list and gives it the necessary parameters to complete theoperations. The batch manager 208 then uses this information todetermine which commands can be optimized. One optimization 512 removesoperations that cancel each other, such as deleting a newly createdpartition. Another optimization removes operations that are supersededby later operations, such as moving the same partition twice.

Undo

A simple undo-everything-in-the-current-user-session operation can beimplemented by reinitializing the virtual engine environment 206 fromthe on-disk structures 104, 108. Step-by-step undo of selectedoperations requires that the list of operations be read and the lastoperation be undone by performing the opposite operation (for instance,Hide to undo Unhide, or resize smaller to undo resize larger). Since thelist of operations stores the “before” state of the partition this iseasily done.

Converting Partition Classes

In order to convert a primary partition to a logical partition, theprimary partition must reside adjacent to an extended partition, orthere must not be an existing extended partition 108 on the disk 106. Ifthe primary partition is not notched, the partition must first beresized to add the notch, then the extended partition is created orchanged to encompass the primary partition. Finally, the MBR entry forthe primary partition is deleted and a corresponding EPBR entry iscreated in the extended partition for the newly converted logicalpartition. If the primary partition to be converted is the firstpartition on the disk 106, and starts one head from the beginning of thedisk, the partition must be moved or resized to start one head after thebeginning of the second cylinder on the disk so the extended partitionstarts at the beginning of a cylinder.

To convert a logical partition to a primary partition, the logicalpartition must be the first or last partition in the extended partition.The extended partition will simply be changed to no longer encompass thelogical partition, the EPBR entry will be deleted and a correspondingentry will be created in the MBR for the newly created primarypartition. If the logical partition occupied all available space in theextended partition, then the extended partition can also be deleted.

Summary

The present invention provides tools and techniques for manipulatingvirtual partitions in a virtual engine environment without necessarilycommitting each partition manipulation by actually modifying on-disksystem structures. This has several advantages. It allows users toexperiment with different manipulations in a safe and efficient manner.It allows systems according to the invention to optimize a sequence ofoperations by giving the system a more global view of what is to bedone. It also allows users to collect operations into a batch list,which is then executed automatically without requiring additional userinput at the end of each list entry. The present invention alsointegrates these virtual operations with existing tools and techniquessuch as those employed by the PartitionMagic 3.0 program, whileexpanding those tools and techniques by enhancing the user's ability tomanipulate extended partitions and providing better support for remotepartition manipulation.

Articles of manufacture within the scope of the present inventioninclude a computer-readable program storage medium in combination withthe specific physical configuration of a substrate of the programstorage medium. The substrate configuration represents data andinstructions which cause the computers to operate in a specific andpredefined manner as described herein. Suitable storage devices includefloppy disks, hard disks, tape, CD-ROMs, RAM, and other media readableby one or more of the computers. Each such medium tangibly embodies aprogram, functions, and/or instructions that are executable by themachines to perform partition manipulation substantially as describedherein.

Although particular methods and signal formats embodying the presentinvention are expressly illustrated and described herein, it will beappreciated that system and configured program storage mediumembodiments may be formed according to the signals and methods of thepresent invention. Unless otherwise expressly indicted, the descriptionsherein of methods and signals of the present invention therefore extendto corresponding systems and configured storage media, and thedescriptions of systems and program storage media of the presentinvention extend likewise to corresponding methods and signals.

As used herein, terms such as “a” and “the” and item designations suchas “partition” are inclusive of one or more of the indicated item. Inparticular, in the claims a reference to an item means at least one suchitem is required. When exactly one item is intended, this document willstate that requirement expressly.

The invention may be embodied in other specific forms without departingfrom its essential characteristics. The described embodiments are to beconsidered in all respects only as illustrative and not restrictive.Headings are for convenience only. The scope of the invention is,therefore, indicated by the appended claims rather than by the foregoingdescription. All changes which come within the meaning and range ofequivalency of the claims are to be embraced within their scope.

What is claimed and desired to be secured by patent is:
 1. A method forcomputer partition manipulation, comprising the steps of: obtaining froma user at least one user command, each user command corresponding to atleast one desired operation on a virtual partition, each virtualpartition corresponding at least initially to a live partition on acomputer storage medium, each virtual partition having a specifiedstarting sector address and a specified ending sector address, and alsohaving an indication whether the virtual partition is formatted to afile system; simulating the performance of at least one of the desiredpartition operations to obtain simulation results by manipulating thevirtual partition without necessarily modifying on-disk systemstructures that specify the live partition; and providing the simulationresults to the user.
 2. The method of claim 1, wherein the providingstep provides the simulation results to a computerized user through adata transfer.
 3. The method of claim 1, wherein the providing stepprovides the simulation results to a human user through a display in auser interface.
 4. The method of claim 1, further comprising the step ofperforming live partition manipulation by modifying at least one on-disksystem structure that specifies the live partition on the non-volatilecomputer storage medium.
 5. The method of claim 4, wherein the modifiedon-disk system structure specifies the size of the live partition insectors.
 6. The method of claim 4, wherein the modified on-disk systemstructure specifies the cluster size of the live partition.
 7. Themethod of claim 4, wherein the modified on-disk system structurespecifies whether the live partition is an extended partition.
 8. Themethod of claim 4, wherein the modified on-disk system structurespecifies a file system used within the live partition.
 9. The method ofclaim 1, wherein the obtaining step comprises obtaining the commandinteractively from a user.
 10. The method of claim 1, wherein thecommand is obtained from a remote user over a communications link, thecomputer to which the non-volatile computer storage medium is attachedis local, and the simulating step locally simulates at least oneoperation which may be performed locally in response to the remoteuser's command.
 11. The method of claim 1, wherein the command isobtained from a remote user over a communications link, the computer towhich the non-volatile computer storage medium is attached is local, andthe simulating step remotely simulates at least one operation which maybe performed locally in response to the remote user's command.
 12. Themethod of claim 1, wherein the command is obtained from a remote userover a communications link, the computer to which the non-volatilecomputer storage medium is attached is remote, and the simulating steplocally simulates at least one operation which may be performed remotelyin response to the remote user's command.
 13. The method of claim 1,wherein the command is obtained from a remote user over a communicationslink, the computer to which the non-volatile computer storage medium isattached is remote, and the simulating step remotely simulates at leastone operation which may be performed remotely in response to the remoteuser's command.
 14. The method of claim 1, wherein the simulating stepincludes simulated partition creation.
 15. The method of claim 14,wherein the simulating step creates a simulated logical partition. 16.The method of claim 14, wherein the simulating step creates a simulatedprimary partition.
 17. The method of claim 14, wherein the simulatingstep creates a simulated extended partition.
 18. The method of claim 1,wherein the simulating step includes simulated partition formatting. 19.The method of claim 1, wherein the simulating step includes simulatedpartition replication.
 20. The method of claim 1, wherein the simulatingstep includes simulated partition deletion.
 21. The method of claim 1,wherein the simulating step includes simulated partition resizing bychanging the number of sectors in a simulated partition.
 22. The methodof claim 1, wherein the simulating step includes simulated partitionresizing by changing the cluster size of a simulated partition.
 23. Themethod of claim 1, wherein the simulating step includes changing theroot directory size of a simulated partition.
 24. The method of claim 1,wherein the simulating step includes simulated partition resizing bychanging the size of a simulated extended partition in connection withresizing a simulated logical partition within the simulated extendedpartition.
 25. The method of claim 1, wherein the simulating stepincludes simulated partition resizing by expanding a simulated extendedpartition into free space obtained by manipulating a simulated partitionoutside the simulated extended partition.
 26. The method of claim 1,wherein the simulating step includes renaming a simulated partition. 27.The method of claim 1, wherein the simulating step includes simulatedpartition conversion by changing the file system type of a simulatedpartition.
 28. The method of claim 27, wherein the conversion changesfile system type between FAT16 and FAT32 file systems.
 29. The method ofclaim 27, further comprising the step of displaying an indication of thesimulated partition's free space after the conversion.
 30. The method ofclaim 27, further comprising the step of displaying an indication of thesimulated partition's used space after the conversion.
 31. The method ofclaim 1, wherein the simulating step includes changing the hidden statusof a simulated partition.
 32. The method of claim 1, wherein thesimulating step includes changing the active status of a simulatedpartition.
 33. The method of claim 1, wherein the simulating stepinserts a placeholder in a list of desired partition operations for astep of verifying the integrity and consistency of live internal filesystem data.
 34. The method of claim 1, wherein the simulating stepinserts a placeholder in a list of desired partition operations for astep of testing for bad sectors in a live partition.
 35. The method ofclaim 1, further comprising the steps of obtaining a partitionconstraint from the user and enforcing the partition constraint duringthe simulating step.
 36. The method of claim 35, wherein the partitionconstraint specifies whether a partition can be moved.
 37. The method ofclaim 35, wherein the partition constraint specifies whether a partitioncan be resized.
 38. The method of claim 1, wherein the simulating stepupdates a virtual engine environment data structure in computer memoryand the method further comprises storing the virtual engine environmentdata structure in persistent storage as user data.
 39. The method ofclaim 1, further comprising the step of editing a list of desiredpartition operations.
 40. The method of claim 39, further comprising thestep of storing the list of desired partition operations in persistentstorage as user data.
 41. The method of claim 39, wherein the editingstep comprises interactive editing by the user.
 42. The method of claim41, wherein the interactive editing undoes at least one operationpreviously specified by the user.
 43. The method of claim 39, whereinthe editing step comprises computer-implemented optimization of the listto reduce the time needed to perform the list.
 44. The method of claim43, wherein the optimization removes a first set of one or morepartition operations that is made redundant by a second, later set ofone or more partition operations.
 45. The method of claim 43, whereinthe optimization reduces the amount of data movement required by a setof partition operations.
 46. The method of claim 1, further comprisingthe computer-implemented step of optimizing the list of desiredpartition operations to optimize storage device use.
 47. The method ofclaim 46, wherein the optimized list redistributes free space on thestorage device.
 48. The method of claim 46, wherein the optimized listincreases free space on the storage device by reducing cluster size. 49.The method of claim 46, wherein the optimized list increases free spaceon the storage device by converting file system type.
 50. The method ofclaim 46, wherein the optimized list specifies free space and thencreates an operating system partition for installing an operatingsystem.
 51. The method of claim 50, wherein the optimized list adds theoperating system partition to a boot manager structure.
 52. The methodof claim 1, further comprising the step of verifying the integrity andconsistency of live internal file system data.
 53. The method of claim1, further comprising the step of verifying the integrity andconsistency of partition size and position relative to a storage deviceboundary.
 54. The method of claim 1, further comprising the step ofverifying the integrity and consistency of partition size and positionrelative to another partition.
 55. The method of claim 1, furthercomprising a portion of the step of performing live partitionmanipulation, wherein the performing step is interrupted.
 56. The methodof claim 55, wherein the computer is forcibly rebooted before completionof the performing step.
 57. A computer program storage medium having aconfiguration that represents data and instructions which will cause atleast a portion of a computer system to perform method steps forpartition manipulation, the method steps comprising the steps of:obtaining from a user at least one user command, each user commandcorresponding to at least one desired operation on a virtual partition,each virtual partition corresponding at least initially to a livepartition on a non-volatile computer storage device; simulating theperformance of at least one of the desired partition operations toobtain simulation results by manipulating the virtual partition withoutnecessarily modifying on-device system structures that specify the livepartition; and providing the simulation results to the user.
 58. Theconfigured program storage medium of claim 57, wherein the methodfurther comprises the step of performing at least partial manipulationof a live partition by modifying at least one on-device system structurethat specifies the live partition on the non-volatile storage device.59. The configured program storage medium of claim 58, wherein theperforming step is started in response to a user command received from aremote computer over a communications link.
 60. The configured programstorage medium of claim 58, wherein the simulating step updates avirtual engine data structure in computer memory and the performing stepupdates a corresponding data structure on the non-volatile storagedevice.
 61. The configured program storage medium of claim 60, whereinthe data structure on the non-volatile storage device includes apartition table.
 62. The configured program storage medium of claim 60,wherein the data structure on the non-volatile storage device includes afile allocation table.
 63. The configured program storage medium ofclaim 60, wherein the data structure on the non-volatile storage deviceincludes a boot record.
 64. The configured program storage medium ofclaim 60, wherein the data structure on the non-volatile storage deviceincludes a root directory.
 65. The configured program storage medium ofclaim 60, wherein the virtual engine data structure specifies a startingsector address and a sector count for a virtual partition.
 66. Theconfigured program storage medium of claim 65, wherein the virtualengine data structure specifies a file system type for the virtualpartition.
 67. The configured program storage medium of claim 60,wherein the virtual engine data structure specifies a total directorycount and a total file count for the virtual partition.
 68. Theconfigured program storage medium of claim 60, wherein the virtualengine data structure specifies a cluster size for the virtualpartition.
 69. The configured program storage medium of claim 60,wherein the virtual engine data structure specifies a geometry for avirtual drive.
 70. The configured program storage medium of claim 58,wherein the performing step comprises receiving an identification of thesimulated partition operation over a communications link.
 71. Theconfigured program storage medium of claim 58, further comprising thestep of undoing an operation previously done during at least one of thesimulating step and the performing step.
 72. The configured programstorage medium of claim 71, wherein the undoing step undoes a partitioncreation operation.
 73. The configured program storage medium of claim71, wherein the undoing step undoes a partition deletion operation. 74.The configured program storage medium of claim 71, wherein the undoingstep undoes a partition replication operation.
 75. The configuredprogram storage medium of claim 71, wherein the undoing step undoes apartition resizing operation.
 76. The configured program storage mediumof claim 71, wherein the undoing step undoes a partition free spaceredistribution operation.
 77. The configured program storage medium ofclaim 71, wherein the undoing step undoes a partition renamingoperation.
 78. The configured program storage medium of claim 71,wherein the undoing step undoes a partition file type conversionoperation.
 79. A computer partition manipulation system comprising: aninterface to obtain from a user a command which corresponds to at leastone desired partition operation on a simulated partition and to providesimulation results to the user, the simulated partition having aspecified starting sector address and a specified ending sector address,and also having an indication whether the simulated partition isformatted to a file system; at least one processor; and a memoryaccessible to the processor and configured by data and instructionsforming a virtual engine environment structure whereby the systemsimulates performance of at least one desired partition operation. 80.The system of claim 79, further comprising a real engine formanipulation of live partitions on a non-volatile computer storagemedium, the real engine in operable communication with the systemwhereby the real engine accepts commands previously supplied by theinterface to the virtual engine environment.
 81. The system of claim 80,wherein the real engine comprises an application program that runs inalternate execution mode.
 82. The system of claim 80, wherein the systemcomprises a batch manager that supplies a list of operations to the realengine.
 83. The system of claim 79, wherein the interface comprises acommunications link for communication with a remote computer.
 84. Thesystem of claim 83, wherein the storage medium is directly attached tothe same computer as the virtual engine data structure.
 85. The systemof claim 83, wherein the storage medium is directly attached to theremote computer.
 86. The system of claim 79, wherein the virtual engineenvironment structure includes a virtual partition.
 87. The system ofclaim 79, wherein the virtual engine environment structure includes avirtual drive.
 88. The system of claim 79, wherein the virtual engineenvironment structure includes a virtual file system object.
 89. Thesystem of claim 79, wherein the virtual engine environment structureincludes a virtual file system limits object.
 90. The system of claim80, wherein the system comprises a means for performing live partitioncreation.
 91. The system of claim 90, wherein the means for performinglive partition creation creates a live partition on a remote computer byway of a communications link.
 92. The system of claim 80, wherein thesystem comprises a means for simulating partition replication.
 93. Thesystem of claim 92, wherein the system further comprises a means forperforming live partition replication.
 94. The system of claim 93,wherein the means for performing live partition replication replicates alive partition on a remote computer by way of a communications link. 95.The system of claim 80, wherein the system simulates a desired partitionoperation of partition resizing by changing the number of sectors in asimulated partition.
 96. The system of claim 95, wherein the systemperforms live partition resizing by changing the number of sectors in alive partition on the non-volatile computer storage medium.
 97. Thesystem of claim 96, wherein the system resizes the live partition on aremote computer by way of a communications link.
 98. The system of claim80, wherein the system simulates a desired partition operation ofpartition resizing by changing the cluster size of a simulatedpartition.
 99. The system of claim 98, wherein the system furthercomprises means for performing live partition resizing by changing thecluster size of a live partition.
 100. The system of claim 99, whereinthe means for performing live partition resizing resizes the livepartition on a remote computer by way of a communications link.
 101. Thesystem of claim 79, further comprising a means for editing a list ofdesired partition operations.
 102. The system of claim 99, wherein themeans for editing a list of desired partition operations comprisescomputer-implemented means for optimizing the list to reduce the timeneeded to perform the list.
 103. The system of claim 79, furthercomprising a means for coordinating partition manipulation with bootmanagement, whereby a user selects a live partition to boot; if theselected partition is already a primary partition then the boot managerboots from that partition; if the selected partition is a logicalpartition and a partition table entry is open then the selected logicalpartition is changed to a primary partition and entered in the partitiontable, an extended partition holding the former logical partition isresized to exclude it, and the boot manager boots from the new primarypartition; and if no partition table entry is available, then anon-extended primary partition is moved into the extended partition,thereby becoming a logical partition and freeing a partition table entryfor use by the selected partition which is to be booted.
 104. The systemof claim 79, comprising at least two computers connected by acommunications link, the interface running at least in part on one ofthe computers and the virtual engine environment residing at least inpart on the other computer.
 105. The system of claim 79, wherein thesystem comprises a means for converting a primary partition to a logicalpartition.
 106. The system of claim 79, wherein the system comprises ameans for converting a logical partition to a primary partition.